Trusted and secure techniques, systems and methods for item delivery and execution

ABSTRACT

Documents and other items can be delivered electronically from sender to recipient with a level of trustedness approaching or exceeding that provided by a personal document courier. A trusted electronic go-between can validate, witness and/or archive transactions while, in some cases, actively participating in or directing the transaction. Printed or imaged documents can be marked using handwritten signature images, seal images, electronic fingerprinting, watermarking, and/or steganography. Electronic commercial transactions and transmissions take place in a reliable, “trusted” virtual distribution environment that provides significant efficiency and cost savings benefits to users in addition to providing an extremely high degree of confidence and trustedness. The systems and techniques have many uses including but not limited to secure document delivery, execution of legal documents, and electronic data interchange (EDI).

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of application Ser. No. 11/102,514,filed Apr. 7, 2005, which is a division of application Ser. No.09/632,944, filed Aug. 4, 2000, now U.S. Pat. No. 7,143,290, which is acontinuation of application Ser. No. 09/221,479, filed Dec. 28, 1998,now U.S. Pat. No. 6,185,683, which is a continuation of application Ser.No. 08/699,711, filed Aug. 12, 1996, now abandoned, which is acontinuation-in-part of application Ser. No. 08/388,107, filed Feb. 13,1995, abandoned via file wrapper continuation, now U.S. Pat. No.5,982,891, all of which are incorporated herein by reference.

FIELD OF THE INVENTION(S)

These inventions relate to secure and trusted delivery of digitalinformation. More specifically, these inventions pertain to techniques,methods and systems for providing reliable, trusted, verifiabledelivery, handling, creation and/or execution of digital items such asdocuments, executable code (e.g., Java applets), and/or any otherinformation capable of being represented in digital form. The presentinvention also relates to commercial and other electronic activitiesinvolving a trusted third party electronic go-between (such as acomputer controlled process) to audit, validate, and/or directelectronic transactions, executions and/or delivery and/or to archiveinformation representing and/or at least in part comprising securelycommunicated digital information.

BACKGROUND AND SUMMARY OF THE INVENTIONS

There is a great need for convenient, cost effective techniques tosecurely handle and deliver documents and other items. Existing methodssuch as express and personal couriers, registered mail, facsimile andelectronic mail fulfill some of these needs but these techniques eachhave their problems and are deficient in important ways.

Trusted Personal Couriers

Perhaps the ultimate in secure document handling is the personal trustedcourier. Many of us have seen spy films showing a trusted courierdelivering documents containing state secrets. In such scenarios, thedocument sender places the document or other item into a lockableattaché case. The sender seals and locks the case with a key orcombination that only he and the recipient have. The courier handcuffsthe case to his or her wrist, boards an airplane and flies to therequired destination—all the while carefully guarding the attaché caseand its contents. Upon arriving at the destination, the courierpersonally delivers the case to the intended recipient. The recipientunlocks the case and retrieves its contents, all the while having a highdegree of assurance that the contents have been kept secret.

The confidentiality, security and reliability provided by a personaltrusted document courier has never really been matched by any other formof document delivery. Even though we sometimes might want or need theservices of a personal trusted document courier, it is likely thatpractical reasons (such as cost and availability) require us to use lesstrusted forms of delivery for even our most important and confidentialdocuments or other items. Moreover, even the trusted courier techniquedoes not provide a reliable means of later providing how and when theinformation was used by the recipient and/or subsequently handled byothers to whom the recipient may pass the information and whatinformation was actually sent. This approach also cannot provide thedegree of interactivity between the sender and the recipient possible ina world of near instantaneous communications, including seamlesslysupporting processes related to rights management, and document creationand dissemination.

As discussed below, existing alternatives to the trusted courier aremore practical and less expensive, and some offer advantages such asinstantaneous communications and interactivity—but all suffer fromvarious disadvantages.

Express Courier Services

Federal Express and other express courier services provide rapid (forexample, overnight) delivery services at a relatively high degree oftrustedness.

In the typical case, the sender places the items to be delivered into aspecial, tear resistant sealed envelope, and fills out an “air bill”that lists the sender's name, address and telephone number, and theintended recipient's name, address and telephone number. The “air bill”also lists options such as, for example, the type of delivery servicerequired (i.e., delivery next business morning, next business afternoon,or second business day), whether the sender requires Federal Express toobtain the recipient's signature, the payment method, and a unique“tracking number” used to uniquely identify the package.

Once the package is complete and ready to send, the sender may provideit to Federal Express through a number of different methods:

-   -   the sender may take the package to a Federal Express office and        personally hand it to a clerk,    -   the sender may drop the completed envelope in any one of many        pervasive Federal Express drop off boxes, and someone will come        and collect the envelopes from the boxes sometime before the end        of the business day and deliver them to a Federal Express        office, or    -   the sender can call Federal Express and arrange for a delivery        person to come and pick up the package.

Federal Express maintains a fleet of aircraft that shuttle most packagesto a central sorting and routing facility for subsequent dispatch tovarious destinations across the United States and the world. A fleet ofdelivery trucks deliver the packages from local airports to eachrecipient. At the sender's option, a delivery person may obtain arecipient's signature at the time she delivers the package—providingdocumentation that may later be used to prove the package was in factreceived by the intended recipient or someone at his or her home oroffice.

Federal Express uses automated computer tracking and package handlingequipment to route individual packages to their destinations. Deliveryinformation is put into the tracking computer to allow customers andservice people to automatically retrieve information about when and towhom particular packages were actually delivered, or where the packagehappens to be at the moment.

Federal Express and other similar document delivery services have beenhighly successful because they cost-effectively ensure reliable deliveryof original documents and other items. Nevertheless, they do have somesignificant disadvantages and limitations. For example:

-   -   They are much more expensive than other delivery mechanisms at        least in part because of the high labor, transportation, and        infrastructure (many offices, planes, etc.) costs involved.    -   They do not provide the very high degree of confidentiality        desired for certain confidential business or other documents.    -   They generally can only reliably verify that the package was        delivered to the intended recipient (or his or her home or place        of business)—and not that the intended recipient opened the        package or read or saw or used the document.    -   The one (or two) day delay they introduce may be too great for        time sensitive or time pressing items.

These problems are exacerbated when several individuals and/ororganizations in different geographical locations are all parties to atransaction—a complex, multiparty contract, for example—and all mustsign or otherwise process and/or execute one or more related documents.

Registered Mail

A relatively more secure delivery technique is registered mail.Registered mail correspondents can have a high degree of confidence thattheir packages will arrive at their required destinations—but may notlike the time delays and additional expense associated with this specialform of mail handling.

To use registered mail, the sender places her document or other itemsinto a sealed envelope or package and takes her package to the nearestPost Office. For security, the Post Office may prohibit the use ofresealable tape and mailing labels, and instead require the package tobe sealed with paper tape and the address to be written directly on thepackage. These safeguards help to ensure that any attempts to tamperwith the package or its contents will be detected.

The Post Office securely transports the registered mail package to therecipient, requiring each postal employee who accepts custody of thepackage along its journey to sign and time stamp a custody record. Thepostal carrier at the recipient's end personally delivers the package tothe recipient—who also has to sign for it and may be asked to produceproof of identification. The custody record establishes a chain ofcustody, listing every person who has had custody of the package on itsjourney from sender to recipient.

As discussed above, registered mail is relatively secure andconfidential but delivery takes a long time and is very labor andinfrastructure intensive.

Facsimile

Facsimile is an electronic-based technology that provides virtuallyinstantaneous document delivery. A facsimile machine typically includesa document scanner, a document printer, and electronic circuits thatconvert document images to and from a form in which they can be sentover a telephone line. Facsimile requires each of the sender and theintended recipient to have a facsimile machine. The sender typicallyplaces the document to be sent into a document feeder attached to afacsimile machine. The sender then typically keys in the telephonenumber of the intended recipient's facsimile machine and presses a“start” button. The sender's facsimile machine automatically dials andestablishes contact with the recipient's facsimile machine.

Once a good connection is established, the sender's facsimile machinebegins to optically scan the document one page at a time and convert itinto digital information bits. The sender's facsimile machine convertsthe digital bits into a form that can be transmitted over a telephoneline, and sends the bits to the intended recipient's facsimile machine.The sender's facsimile machine may also send as part of the document, a“header” on the top of each page stating the sender's identity, the pagenumber of the transmission, and the transmission time. However, theseheaders can be changed at will by the sender and therefore cannot betrusted.

Since the recipient's facsimile machine receives the transmittedinformation at the same time the sender's facsimile machine is sendingit, delivery is virtually instantaneous. However, sending a document toan unattended facsimile machine in an insecure location may result inthe document falling into the wrong hands. Another common scenario isthat the facsimile machine operator, through human error, dials thewrong telephone number and ends up delivering a confidential document tothe wrong person (for example, the local grocery store down the street,or in some unfortunate cases, the opposing side of a negotiation, legalproceeding or other pitched battle). Thousands of faxes are lost everyday in a “black hole”—never arriving at their desired destinations butpossibly arriving at completely different destinations instead.

-   -   Some secure facsimile machines such as those used by government        and military organizations, or by companies needing a        significantly higher level of security provide an extra        security/authentication step to ensure that the intended        recipient is physically present at the receiving facsimile        machine before the sender's machine will transmit the document.        In addition, it is possible to use encryption to prevent the        facsimile transmitted information from being understood by        electronic eavesdroppers. However, such specially equipped        facsimile machines tend to be very expensive and are not        generally available for common commercial facsimile traffic.        Moreover, facsimile machines typically can send and receive        documents only—and therefore are not very versatile. They do        not, for example, handle digital items such as audio, video,        multimedia, and executables, yet these are increasingly part and        parcel of communications for commerce and other purposes. Thus,        despite its many advantages, facsimile transmissions do not        provide the very high degree of trustedness and confidence        required by extremely confidential documents, nor do they        provide the degree of flexibility required by modern digital        communications. As with Express Courier Services and Registered        Mail, faxing can only indicate that the package was delivered to        the intended recipient (or his or her home or place of        business)—and not that the intended recipient opened the package        or read or saw or used the document.

Electronic Mail

More and more, people are using electronic mail to send documents,messages, and/or other digital items. The “Internet explosion” hasconnected millions of new users to the Internet. Whereas Internetelectronic mail was previously restricted primarily to the academicworld, most corporations and computer-savvy individuals can nowcorrespond regularly over the Internet.

Currently, Internet electronic mail provides great advantages in termsof timeliness (nearly instantaneous delivery) and flexibility (any typeof digital information can be sent), but suffers from an inherent lackof security and trustedness. Internet messages must typically passthrough a number of different computers to get from sender to recipient,regardless of whether these computers are located within a singlecompany on an “Intranet” for example, or on Internet attached computersbelonging to a multitude of organizations. Unfortunately, any one ofthose computers can potentially intercept the message and/or keep a copyof it. Moreover, even though some of these systems have limited “returnreceipt” capabilities, the message carrying the receipt suffers from thesame security and reliability problems as the original message.

Cryptography (a special mathematical-based technique for keepingmessages secret and authenticating messages) is now beginning to be usedto prevent eavesdroppers from reading intercepted messages, but thewidespread use of such cryptography techniques alone will not solveelectronic mail's inherent lack of trustedness. These electronic mailmessages, documents and other items (e.g., executable computer programsor program fragments) that might have been sent with them as“attachments,” remain vulnerable to tampering and other unauthorizedoperations and uses once decrypted and while delivery may be reported,actual use can not be demonstrated. Some people have tried to develop“privacy enhanced” electronic mail, but prior systems have only providedlimited improvements in reliability, efficiency and/or security.

The Present Inventions Solve These and Other Problems

As discussed above, a wide variety of techniques are currently beingused to provide secure, trusted confidential delivery of documents andother items. Unfortunately, none of these previously existing mechanismsprovide truly trusted, virtually instantaneous delivery on acost-effective, convenient basis and none provide rights management andauditing through persistent, secure, digital information protection.

In contrast, the present inventions provide the trustedness,confidentiality and security of a personal trusted courier on avirtually instantaneous and highly cost-effective basis. They providetechniques, systems and methods that can bring to any form of electroniccommunications (including, but not limited to Internet and internalcompany electronic mail) an extremely high degree of trustedness,confidence and security approaching or exceeding that provided by atrusted personal courier. They also provide a wide variety of benefitsthat flow from rights management and secure chain of handling andcontrol.

The present inventions preferred embodiment make use of a digitalVirtual Distribution Environment (VDE) as a major portion of itsoperating foundation, providing unique, powerful capabilitiesinstrumental to the development of secure, distributed transaction-basedelectronic commerce and digital content handling, distribution,processing, and usage management. This Virtual Distribution Environmenttechnology can flexibly enable a wide variety of new business models andbusiness practices while also supporting existing business models andpractices.

The Virtual Distribution Environment provides comprehensive overallsystems, and wide arrays of methods, techniques, structures andarrangements, that enable secure, efficient electronic commerce andrights management on the Internet and other information superhighwaysand on internal corporate networks such as “Intranets”. The presentinventions use (and in some cases, build upon and enhances) thisfundamental Virtual Distribution Environment technology to provide stilladditional flexibility, capabilities, features and advantages. Thepresent invention, in its preferred embodiment, is intended to be usedin combination a broad array of the features described in Ginter, et al,including any combination of the following:

A. VDE chain of handling and control,

B. security trusted internodal communication,

C. secure database,

D. authentication,

E. cryptographic,

F. fingerprinting,

G. other VDE security and communication techniques,

H. rights operating system,

I. object design and secure container techniques,

J. container control structures,

K. ARPML rights and process control language,

L. electronic negotiation,

M. secure hardware, and

N. smart agent (smart object) techniques.

For example, parties using the Virtual Distribution Environment canparticipate in commerce and other transactions in accordance with apersistent set of rules they electronically define. Such techniques,systems and arrangements bring about an unparalleled degree of security,reliability, efficiency and flexibility to electronic commerce,electronic rights management and other important business models. Thepresent inventions make use of these persistent electronic rules toprovide secure, automated, cost-effective electronic control forelectronic document and other digital item handling and/or delivery, andfor the electronic formation and negotiation of legal contracts andother documents.

By way of non-exhaustive summary, these present inventions provide ahighly secure and trusted item delivery and agreement execution servicesproviding the following features and functions:

-   -   Trustedness and security approaching or exceeding that of a        personal trusted courier.    -   Instant or nearly instant delivery.    -   Optional delayed delivery (“store and forward”).    -   Broadcasting to multiple parties.    -   Highly cost effective.    -   Trusted validation of item contents and delivery.    -   Value Added Delivery and other features selectable by the sender        and/or recipient.    -   Provides electronic transmission trusted auditing and        validating.    -   Allows people to communicate quickly, securely, and        confidentially.    -   Communications can later be proved through reliable evidence of        the communications transaction—providing non-repudiatable,        certain, admissible proof that a particular communications        transaction occurred.    -   Provides non-repudiation of use and may record specific forms of        use such as viewing, editing, extracting, copying,        redistributing (including to what one or more parties), and/or        saving.    -   Supports persistent rights and rules based document workflow        management at recipient sites.    -   System may operate on the Internet, on internal organization        and/or corporate networks (“Intranets” irrespective of whether        they use or offer Internet services internally), private data        networks, and/or using any other form of electronic        communications.    -   System may operate in non-networked and/or intermittently        networked environments.    -   Legal contract execution can be performed in real time, with or        without face to face or ear-to-ear personal interactions (such        as audiovisual teleconferencing, automated electronic        negotiations, or any combination of such interactions) for any        number of distributed individuals and/or organizations using any        mixture of interactions.    -   The items delivered and/or processed may be any “object” in        digital format, including, but not limited to, objects        containing or representing data types such as text, images,        video, linear motion pictures in digital format, sound        recordings and other audio information, computer software, smart        agents, multimedia, and/or objects any combination of two or        more data types contained within or representing a single        compound object.    -   Content (executables for example) delivered with proof of        delivery and/or execution or other use.    -   Secure electronic containers can be delivered. The containers        can maintain control, audit, receipt and other information and        protection securely and persistently in association with one or        more items.    -   Trustedness provides non-repudiation for legal and other        transactions.    -   Can handle and send any digital information (for example, analog        or digital information representing text, graphics, movies,        animation, images, video, digital linear motion pictures, sound        and sound recordings, still images, software computer programs        or program fragments, executables, data, and including multiple,        independent pieces of text; sound clips, software for        interpreting and presenting other elements of content, and        anything else that is electronically representable).    -   Provides automatic electronic mechanisms that associate        transactions automatically with other transactions.    -   System can automatically insert or embed a variety of visible or        invisible “signatures” such as images of handwritten signatures,        seals, and electronic “fingerprints” indicating who has        “touched” (used or other interacted with in any monitorable        manner) the item.    -   System can affix visible seals on printed items such as        documents for use both in encoding receipt and other receipt        and/or usage related information and for establishing a visible        presence and impact regarding the authenticity, and ease of        checking the authenticity, of the item.    -   Seals can indicate who originated, sent, received, previously        received and redistributed, electronicallyview, and/or printed        and/or otherwise used the item.    -   Seals can encode digital signatures and validation information        providing time, location, sender and/or other information and/or        providing means for item authentication and integrity check.    -   Scanning and decoding of item seals can provide        authenticity/integrity check of entire item(s) or part of an        item (e.g., based on number of words, format, layout,        image—picture and/or text—composition, etc.).    -   Seals can be used to automatically associate electronic control        sets for use in further item handling.    -   System can hide additional information within the item using        “steganography” for later retrieval and analysis.    -   Steganography can be used to encode electronic fingerprints        and/or other information into an item to prevent deletion.    -   Multiple steganographic storage of the same fingerprint        information may be employed reflecting “more” public and “less”        public modes so that a less restricted steganographic mode        (different encryption algorithm, keys, and/or embedding        techniques) can be used to assist easy recognition by an        authorized party and a more private (confidential) mode may be        readable by only a few parties (or only one party) and comprise        of the less restricted mode may not affect the security of the        more private mode.    -   Items such as documents can be electronically, optically scanned        at the sender's end—and printed out in original, printed form at        the recipient's end.    -   Document handlers and processors can integrate document scanning        and delivery.    -   Can be directly integrated into enterprise and Internet (and        similar network) wide document workflow systems and        applications.    -   Secure, tamper-resistant electronic appliance, which may employ        VDE SPUs, used to handle items at both sender and recipient        ends.    -   “Original” item(s) can automatically be destroyed at the        sender's end and reconstituted at the recipient's end to prevent        two originals from existing simultaneously.    -   Secure, non-repudiable authentication of the identification of a        recipient before delivery using any number of different        authentication techniques including but not limited to biometric        techniques (such as palm print scan, signature scan, voice scan,        retina scan, iris scan, biometric fingerprint and/or handprint        scan, and/or face profile) and/or presentation of a secure        identity “token.”    -   Non-repudiation provided through secure authentication used to        condition events (e.g., a signature is affixed onto a document        only if the system securely authenticates the sender and her        intention to agree to its contents).    -   Variety of return receipt options including but not limited to a        receipt indicating who opened a document, when, where, and the        disposition of the document (stored, redistributed, copied,        etc.). These receipts can later be used in legal proceedings        and/or other contexts to prove item delivery, receipt and/or        knowledge.    -   Audit, receipt, and other information can be delivered        independently from item delivery, and become securely associated        with an item within a protected processing environment.    -   Secure electronic controls can specify how an item is to be        processed or otherwise handled (e.g., document can't be        modified, can be distributed only to specified persons,        collections of persons, organizations, can be edited only by        certain persons and/or in certain manners, can only be viewed        and will be “destroyed” after a certain elapse of time or real        time or after a certain number of handlings, etc.)    -   Persistent secure electronic controls can continue to supervise        item workflow even after it has been received and “read.”    -   Use of secure electronic containers to transport items provides        an unprecedented degree of security, trustedness and        flexibility.    -   Secure controls can be used in conjunction with digital        electronic certificates certifying as to identity, class (age,        organization membership, jurisdiction, etc.) of the sender        and/or receiver and/or user of communicated information.    -   Efficiently handles payment and electronic addressing        arrangements through use of support and administrative services        such as a Distributed Commerce Utility as more fully described        in the copending Shear, et al. application.    -   Compatible with use of smart cards, including, for example, VDE        enabled smart cards, for secure personal identification and/or        for payment.    -   Transactions may be one or more component transactions of any        distributed chain of handling and control process including        Electronic Data Interchange (EDI) system, electronic trading        system, document workflow sequence, and banking and other        financial communication sequences, etc.

The present inventions also provide for the use of a trusted third partyelectronic go-between or intermediary in various forms, including the“virtual presence” of such go-between through the rules and controls itcontributes for distributed governance of transactions described in thepresent invention, and further through the use of a distributed,go-between system operating in on-line and/or off-line modes at varioususer and/or go-between sites. Such a trusted third-party go-between canprovide enhanced and automated functionality, features and otheradvantages such as, for example:

-   -   Third party go-between can provide an independent, objective        third party assurance of item authenticity, integrity, delivery        and/or other actions and/or events.    -   Third party go-between can support non-repudiation of items        having legal and/or other important consequences.    -   Third-party go-between can perform auditing, notarizing,        authentication, integrity checking, archiving, routing,        distributed chain of handling and control processing, and/or        other processing.    -   Third party can provide store and forward capabilities.    -   Trusted go-between can supervise execution of legal items such        as documents—ensuring that all required conditions are satisfied        and that all parties agree before permitting a document to be        executed and informing parties of any as-yet-unsatisfied        requirements and allow parties to view completed documents        on-screen and/or in printed form with “draft, not enforceable”        or the like printed on the pages, before final agreement to        commit. Actual execution (closing) occurs, for example, as the        third party system verifies final, electronically asserted        agreement and execution by all parties. Such “atomic”        transactions are especially useful in supporting “closings” or        the like.    -   Third party go-between can securely audit, manage, supervise,        and/or control automated electronic negotiations, contract        agreement, contract execution, contract notariziation, and/or        archiving of contracts, notarized contracts, and/or at least one        VDE control set utilized in an electronic negotiation regardless        whether or not that negotiation resulted in an executed        contract, and regardless of whether or not the entire        negotiation was conducted by electronic means.    -   Secure electronic controls can direct tasks to be performed by        the third party go-between.    -   Third party go-between can provide a digital time stamp service        to certify that a certain version of a certain document existed        and was delivered to it at a certain day and time.    -   Third party go-between can legally notarize the item(s) if        desired, and can also “notarize” electronic control structures        associated with the item(s).    -   Third party go-between can authenticate an item by, for example,        opening (e.g. decrypting content) one or more containers;        digitally or otherwise “signing” one or more items to indicate        the third party has seen the item(s); verifying the integrity of        the item(s) (e.g., using a one way hash function); affixing its        own distinctive seal and/or other information to the item;        generating audit information for item tracking purposes; and        collecting payment based on the services it has performed.    -   Third party go-between can maintain a secure archive of the        item(s) and/or identification/authentication information        associated with the item(s) (e.g., a “one way hash” value of        item contents or portions thereof). A portion or all of such        archive (e.g., a “one way hash”) may be stored within the        affixed, visible seal applied described above.    -   Go-between can also serve as an archive of controls relating to        certain items or item types (e.g., to allow a sender to access        common controls and/or templates from any of various electronic        appliances).    -   Secure electronic controls can provide a message digest that can        be delivered to and registered by a trusted go-between as part        of the object registry/archiving process.    -   Third party go-between can deliver item(s) to an intended        recipient, or simply oversee the delivery transaction as an        impartial third party observer.    -   Trusted go-between can deliver a copy and/or the original of an        item with or without a seal affixed by the go-between.    -   Trusted third party go-between can maintain or exert control        over an item, distributed chain of handling and control        process(s), and/or other processes or workflow associated with        it.    -   Trusted go-between can support governmental regulatory        requirements by acting as a cryptographic key repository for        encrypted communications; such secure communications may be        accessed by governmental authorities, for example, through a        warrant process to provide court or otherwise mandated access to        specific communications or communications related information        (e.g., for encrypted communications employing long key lengths).    -   Trusted go-between can act as a user rights authority        clearinghouse for additional and/or alternative rights which        may, for example, be available to particular classes, specific        users, at a certain cost, or as specified by the sender. Trusted        go-between may also mediate between sender(s) and recipient(s)        in response to recipient's request for new, different and/or        modified rights or sender's and/or receiver's request for third        party archived information (which may require the agreement by        only one, expressly either one, or both sender(s) and        recipient(s).    -   In addition to multiple individuals and/or parties in several        organizations, a trusted go-between may also provide services to        parties within a single organization, thus enhancing the        security, reliability, auditability, authentication, efficiency,        and timeliness of secure document delivery and secure        transaction facilitation within a given organization.    -   Trusted go-between may provide services both on public networks,        such as the Internet, on internal corporate networks        (“Intranets”—irrespective of whether or not they use Internet        type conventions), and on private networks connecting two or        more individuals and/or organizations exchanging documents and        other content in digital format and/or participating together in        various transactions.    -   A third party go-between can provide a communications switching        integration. For example, a communications service provider may        automatically provide the go-between services for a connection.        For example, certain telephone numbers might be offered that        have these services built in to the switching network, or a        special dialing sequence might be used to access a        communications channel with these characteristics. This can        provide data links for networks, or be integrated with        traditional fax lines, or even voice lines. For example, a fax        transmission might be archived, have a seal inserted during        transmission, and/or have a hash value stored for later        reference. A voice transmission could be similarly managed. Both        of these examples have the advantage of compatibility with the        existing infrastructure (albeit at the cost of lacking        persistent control after delivery). Using this infrastructure        for data links has the added advantage of transparency.    -   A third party go-between can provide Transaction Authority        services as described in the copending concurrently filed Ginter        et al patent application

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features and advantages provided by the presentinvention will become better and more completely understood by studyingthe following detailed description of presently preferred exemplaryembodiments in conjunction with the drawings, of which:

FIG. 1 illustrates an example of a “Virtual Distribution Environment”;

FIG. 1A is a more detailed illustration of an example of the“Information Utility” shown in FIG. 1;

FIG. 2 illustrates an example of a chain of handling and control;

FIG. 2A illustrates one example of how rules and control information maypersist from one participant to another in the FIG. 2 chain of handlingand control;

FIG. 3 shows one example of different control information that may beprovided;

FIG. 4 illustrates examples of some different types of rules and/orcontrol information;

FIGS. 5A and 5B show an example of an “object”;

FIG. 6 shows an example of a Secure Processing Unit (“SPU”);

FIG. 7 shows an example of an electronic appliance;

FIG. 8 is a more detailed block diagram of an example of the electronicappliance shown in FIG. 7;

FIG. 9 is a detailed view of an example of the Secure Processing Unit(SPU) shown in FIGS. 6 and 8;

FIG. 10 shows an example of a “Rights Operating System” (“ROS”)architecture provided by the Virtual Distribution Environment;

FIGS. 11A-11C show examples of functional relationship(s) betweenapplications and the Rights Operating System;

FIGS. 11D-11J show examples of “components” and “component assemblies”;

FIG. 12 is a more detailed diagram of an example of the Rights OperatingSystem shown in FIG. 10;

FIG. 12A shows an example of how “objects” can be created;

FIG. 13 is a detailed block diagram of an example the softwarearchitecture for a “protected processing environment” shown in FIG. 12;

FIGS. 14A-14C are examples of SPU memory maps provided by the protectedprocessing environment shown in FIG. 13;

FIG. 15 illustrates an example of how the channel services manager andload module execution manager of FIG. 13 can support a channel;

FIG. 15A is an example of a channel header and channel detail recordsshown in FIG. 15;

FIG. 15B is a flowchart of an example of program control steps that maybe performed by the FIG. 13 protected processing environment to create achannel;

FIG. 16 is a block diagram of an example of a secure data basestructure;

FIG. 17 is an illustration of an example of a logical object structure;

FIG. 18 shows an example of a stationary object structure;

FIG. 19 shows an example of a traveling object structure;

FIG. 20 shows an example of a content object structure;

FIG. 21 shows an example of an administrative object structure;

FIG. 22 shows an example of a method core structure;

FIG. 23 shows an example of a load module structure;

FIG. 24 shows an example of a User Data Element (UDE) and/or Method DataElement (MDE) structure;

FIGS. 25A-25C show examples of “map meters”;

FIG. 26 shows an example of a permissions record (PERC) structure;

FIGS. 26A and 26B together show a more detailed example of a permissionsrecord structure;

FIG. 27 shows an example of a shipping table structure;

FIG. 28 shows an example of a receiving table structure;

FIG. 29 shows an example of an administrative event log structure;

FIG. 30 shows an example inter-relationship between and use of theobject registration table, subject table and user rights table shown inthe FIG. 16 secure database;

FIG. 31 is a more detailed example of an object registration table shownin FIG. 16;

FIG. 32 is a more detailed example of subject table shown in FIG. 16;

FIG. 33 is a more detailed example of a user rights table shown in FIG.16;

FIG. 34 shows a specific example of how a site record table and grouprecord table may track portions of the secure database shown in FIG. 16;

FIG. 34A is an example of a FIG. 34 site record table structure;

FIG. 34B is an example of a FIG. 34 group record table structure;

FIG. 35 shows an example of a process for updating the secure database;

FIG. 36 shows an example of how new elements may be inserted into theFIG. 16 secure data base;

FIG. 37 shows an example of how an element of the secure database may beaccessed;

FIG. 38 is a flowchart example of how to protect a secure databaseelement;

FIG. 39 is a flowchart example of how to back up a secure database;

FIG. 40 is a flowchart example of how to recover a secure database froma backup;

FIGS. 41A-41D are a set of examples showing how a “chain of handling andcontrol” may be enabled using “reciprocal methods”;

FIGS. 42A-42D show an example of a “reciprocal” BUDGET method;

FIGS. 43A-43D show an example of a “reciprocal” REGISTER method;

FIGS. 44A-44C show an example of a “reciprocal” AUDIT method;

FIGS. 45-48 show examples of several methods being used together tocontrol release of content or other information;

FIGS. 49, 49A-49F show an example OPEN method;

FIGS. 50, 50A-50F show an example of a READ method;

FIGS. 51, 51A-51F show an example of a WRITE method;

FIG. 52 shows an example of a CLOSE method;

FIGS. 53A-53B show an example of an EVENT method;

FIG. 53C shows an example of a BILLING method;

FIG. 54 shows an example of an ACCESS method;

FIGS. 55A-55B show examples of DECRYPT and ENCRYPT methods;

FIG. 56 shows an example of a CONTENT method;

FIGS. 57A and 57B show examples of EXTRACT and EMBED methods;

FIG. 58A shows an example of an OBSCURE method;

FIGS. 58B, 58C show examples of a ELECTRONIC FINGERPRINT method;

FIG. 59 shows an example of a DESTROY method;

FIG. 60 shows an example of a PANIC method;

FIG. 61 shows an example of a METER method;

FIG. 62 shows an example of a key “convolution” process;

FIG. 63 shows an example of how different keys may be generated using akey convolution process to determine a “true” key;

FIGS. 64 and 65 show an example of how protected processing environmentkeys may be initialized;

FIGS. 66 and 67 show example processes for decrypting informationcontained within stationary and traveling objects, respectively;

FIG. 68 shows an example of how a protected processing environment maybe initialized;

FIG. 69 shows an example of how firmware may be downloaded into aprotected processing environment;

FIG. 70 shows an example of multiple VDE electronic appliances connectedtogether with a network or other communications means;

FIG. 71 shows an example of a portable VDE electronic appliance;

FIGS. 72A-72D show examples of “pop-up” displays that may be generatedby the user notification and exception interface;

FIG. 73 shows an example of a “smart object”;

FIG. 74 shows an example of a process using “smart objects”;

FIGS. 75A-75D show examples of data structures used for electronicnegotiation;

FIGS. 75E-75F show example structures relating to an electronicagreement;

FIGS. 76A-76B show examples of electronic negotiation processes;

FIG. 77 shows a further example of a chain of handling and control;

FIG. 78 shows an example of a VDE “repository”;

FIGS. 79-83 show an example illustrating a chain of handling and controlto evolve and transform VDE managed content and control information;

FIG. 84 shows a further example of a chain of handling and controlinvolving several categories of VDE participants;

FIG. 85 shows a further example of a chain of distribution and handlingwithin an organization;

FIGS. 86 and 86A show a further example of a chain of handling andcontrol; and

FIG. 87 shows an example of a virtual silicon container model.

FIG. 88 shows an example trusted electronic delivery system;

FIG. 89 shows a detailed view of an example electronic intelligent kioskappliance;

FIGS. 90A and 90B show example options the sender can select forelectronic delivery;

FIG. 91A shows example steps to send an item;

FIG. 91B shows example steps to receive an item;

FIGS. 92 and 92A show example trusted electronic delivery providing areturn receipt;

FIG. 93 shows example trusted item delivery from an intelligent kiosk toa personal computer;

FIGS. 94 & 95 show examples of trusted electronic delivery betweenpersonal computers;

FIG. 96 shows an example trusted item handling and delivery within anorganization;

FIG. 97 shows an example trusted electronic document execution;

FIG. 98 shows an example multi-party electronic document execution;

FIG. 99 shows an example trusted electronic go-between;

FIG. 100 shows an example use of the trusted electronic go-between fornotarizing and/or archiving;

FIG. 101 shows an example electronic legal contract execution using atrusted electronic go-between;

FIG. 101A shows an example electronic requirements list;

FIG. 101B shows an example multi-party electronic legal contractexecution using a trusted electronic go-between;

FIG. 102 shows example use of trusted electronic go-betweens within andoutside of organizations;

FIG. 103 illustrates an example secure object;

FIG. 104 shows example electronically-generated signatures, seals andelectronic fingerprints;

FIG. 105A shows an example way of hiding information within linespacing;

FIG. 105B shows an example way of hiding information within letterspacing;

FIG. 105C shows an example electronic fingerprint;

FIGS. 106A-106C show example electronically generated seals;

FIGS. 107A and 107B show detailed electronically generated sealexamples;

FIG. 108 shows an example process for creating digital information forencoding into an item or item seal;

FIG. 109 shows an example electronic appliance;

FIGS. 110-113 show example processes for securely sending an item;

FIG. 113A shows an example routing slip data structure;

FIG. 113B shows an example audit trail data structure;

FIG. 114A-118 show example processes for securely receiving an item;

FIG. 119 shows an example architecture for a trusted electronicgo-between;

FIGS. 120A-120B show example reciprocal control set usage to provide atrusted electronic go-between having secure electronic notarizationcapabilities;

FIG. 121 shows example steps performed by a trusted third partygo-between to receive an item;

FIGS. 122 and 123 show example trusted go-between processes;

FIGS. 124A-124B and 125A-125B show example contract execution processes;

FIG. 126 shows an example automobile purchase providing electroniccontract execution through a trusted electronic go-between;

FIG. 127 shows an example use of a trusted electronic go-between toprovide electronic item notarization;

FIG. 128 shows an example secure item delivery with real timeteleconferencing capabilities;

FIG. 129 shows a health insurance example;

FIG. 130 shows an example real estate “atomic” settlement;

FIG. 130A shows example transaction rules;

FIG. 131 shows an example judicial electronic data interchange (EDI);

FIG. 132 shows an example Patent Office automation;

FIG. 133 shows an example tax filing; and

FIG. 134 shows an example using facsimile transmission.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

The entire disclosure of the above-referenced Ginter et al. patentspecification is incorporated by reference in connection with FIGS.1-87.

FIG. 88 shows an electronic trusted delivery system 4050. In thisexample, sender 4052 is sending an item 4054 to a recipient 4056 over anelectronic network 4058. In this example, electronic delivery overnetwork 4058 is by way of a secure, trusted electronic delivery virtualdistribution environment transport mechanism 4060 which is shown forpurposes of illustration as an electronic delivery person. Deliveryperson 4060 is shown as a human being for purposes of illustration, butin the example is actually an automatic, trusted electronic deliverymeans supported and provided by virtual distribution environment 100.

Item 4054 might be a document such as a handwritten or typed letter, orit could be a legal document such as a contract. It could have both textand pictures, just text or just pictures. It could be a sound recording,a multimedia presentation, or a visual work such as a film or televisionprogram. Item 4054 could be any item or information capable of beingrepresented in digital form. The item 4054 can be initially presented tothe appliance 600 in electronic form (for example, on a diskette), orthe appliance can convert it from some other form into electronic form.

Electronic delivery person 4060 receives item 4054 in digital form andplaces it into a secure electronic container 302—thus forming a digital“object” 300. A digital object 300 may in this case be, for example, asshown in FIGS. 5A and 5B, and may include one or more containers 302containing item 4054. FIG. 88 illustrates secure electronic container302 as an attaché case handcuffed to the secure delivery person's wrist.Once again, container is shown as a physical thing for purposes ofillustration only—in the example it is preferably electronic rather thanphysical, and comprises digital information having a well-definedstructure (see FIG. 5A). Special mathematical techniques known as“cryptography” can be used to make electronic container 302 secure sothat only intended recipient 4056 can open the container and access theelectronic document (or other item) 4054 it contains.

In this example, sender 4052 sends item 4054 by supplying the documentto an electronic appliance 600A. In this example, electronic appliance600A is an intelligent electronic walk-up kiosk that may be located in apublic place or on private property, such as the offices or work areasof a firm. Appliance 600A in this example has a document slot 4102 intowhich sender 4052 can feed item 4054. Electronic appliance 600A canautomatically, optically scan the item 4054 and convert it into digitalinformation for sending over an electronic connection or network 4058(such as, for example, electronic highway 108 shown in FIG. 2). The item4054 can be sent to one or many recipients specified by sender 4052.

FIG. 89 shows an example appliance 600A in the form of an intelligentwalk-up kiosk. This example kiosk appliance 600A could be installed inan office building lobby, shopping mall, office supply store, or otherpublic place for walk-up use by members of the public. It could also beinstalled in a location within a corporate or business office (e.g., amail room) for use by company employees. The kiosk appliance 600A is anexample. Aspects of the present invention can be used with other typesof electronic appliances such as personal computers or computerworkstations for example (see FIGS. 7 and 8, and 93-93C for example).

Referring to FIG. 89, the example kiosk appliance 600A can include acomputer screen 4104 for displaying informational messages, and useroperable controls 4106 such as push buttons for allowing sender 4052 toselect between delivery options. Appliance 600 in this example may alsoinclude a card reader 4108 for reading a credit card or other kind ofcard provided by the sender 4052. Additionally, if desired, electronicappliance 600A may include a telephone receiver 4110 and telephonedialing keypad 4112 (or other input devices) to allow sender 4052 to getinformation and assistance or give additional instructions. Electronicappliance 600A may optionally include a keyboard for entering textualand other information (not shown).

Also as shown in FIG. 89, electronic appliance 600A may optionallyinclude a video camera 4124 and may display remote video in a “window”4126 on screen 4104 (or on an optionally separate screen not shown).Camera 4124 allows appliance 600 to take a photograph of sender 4052and/or recipient 4056. It may also allow sender 4052 and recipient 4056to see each other in order to simultaneously authenticate each other'sidentity visually—and to have a “teleconference” discussion about item4054 or other matters. The electronic appliance 600 may also have amicrophone/speaker 4140 perhaps to coordinate details of the pendingtransaction. Appliance 600A might also include a media reader 4132 toread from a floppy diskette, smart card or other digital storage device.The appliance 600 can include, in addition, a documentshredder/destroyer 4115.

Also as shown in FIGS. 88 and 89, appliance 600A in this example has asecure processing unit (SPU) 500 (see FIG. 6). SPU 500 provides atamper-resistant protected processing environment (“PPE”) in whichprocesses and transactions can take place securely and in a trustedfashion.

FIG. 91A shows example steps for sending an item such as item 4054. Tosend item 4054 to recipient 4056, sender 4052 may first press buttons4106 and read display 4104 to select between different delivery options(see FIG. 91A, step 4090A). FIG. 90A shows some example service options,and FIG. 90B shows some more detailed delivery options. For example,sender 4052 might press a button corresponding to “delivery options,”which might cause appliance 600A to display the FIG. 90A menu screen ofvarious delivery options. These delivery options could include, forexample:

-   -   receipt options (what kind of receipt, if any, sender 4052        wishes to receive documenting delivery of item 4054 to intended        recipient 4056);    -   integrity guarantee options (providing high levels of assurance        that item 4054 was delivered in its entirety without any errors,        and without any accidental or intentional modifications);    -   privacy options (for example, whether recipient 4056 is to know        who sender 4052 is or where she has sent the document from); and    -   more options.

Electronic appliance 600A may also ask the user to identify intendedrecipient 4056 (FIG. 91A, step 4090B). Sender 4052 may select differentways to identify recipient 4056 based on the confidentiality of thedocument and the level of security the sender is willing to pay for. Inone example, sender 4052 might require the recipient's appliance 600B torequire recipient 4056 to prove that he is who he says he is. Thissecure “authentication” function might be met by, for example, requiringrecipient 4056 to input a password, present digital proof of identityusing, for example:

-   -   a digital document or “certificate” issued by a trusted third        party, and/or    -   have appliance 600 measure a biometric characteristic of the        recipient such as, for example, taking the recipient's        photograph (and possibly automatically compare it with a known        photograph of the recipient supplied by sender 4052 or system        4050) or using any other biometric sensing technique.

Sender 4052 may also specify the electronic address of recipient 4056,or it might let system 4050 automatically, securely and confidentiallylocate the recipient using a secure directory service as described inthe copending Shear et al. application.

Once sender 4052 has selected the service options she desires, appliance600 may next display a message on computer screen 4104 asking sender4052 to insert item 4054 into document slot 102 for electronic scanning.When the sender 4052 inserts the document 4054 or other item (FIG. 91A,block 4030C), electronic appliance 600 may (if necessary) automatically,optically scan item 4054 to create an electronic, digital form of thedocument (using conventional optical scanning and optical characterrecognition technology, for example). During this scanning process,appliance 600 might display a message on computer screen 4104 such as “Iam scanning your document now . . . ” Instead of feeding in a document,the sender might provide the document or other item in digital form byinserting a floppy diskette or smart card into reader 4132, or byconnecting a portable computer up to port 4130 and having the portablecomputer “upload” the document into appliance 600.

The item 4054 to be sent need not be a document, but could be any typeof item capable of being transformed into digital form such as, forexample:

-   -   pictures or other graphical information;    -   sound information such as voice, music or both;    -   executable computer program or other code;    -   video, film or other moving image sequences;    -   multimedia, video games and the like;    -   any combination or subcombination of the above.

After appliance 600 has scanned or otherwise received the entirety ofdocument 4054 or other item, appliance 600 may calculate and display atotal price on computer screen 4104 and ask sender 4052 to pay for theservice (FIG. 91A, block 4090D). The calculated price may, for example,depend in part on the size and/or number of items to be securelydelivered. The appliance may then ask sender 4052 to confirm she wishesto send the document to the recipient 4056 (FIG. 91A, block 4090E). Uponreceiving that confirmation (FIG. 91A, “y” exit to decision block4090E), appliance 600 may request sender 4052 to pay, for example, byinserting her credit card into card reader 4108 as a form of payment, orit might use other payment arrangements (FIG. 9 aA, block 4090F).Appliance 600 may then package the digital form of document into secureelectronic container 302 and send it over electronic network 4058 forsecure delivery to recipient 4056 (FIG. 91A, block 4090F). Becausesystem 4050 uses the secure “virtual distribution environment” 100,sender 4052 can have a high degree of confidence and trust that item4054 will be usable only by intended recipient(s) 4056 and to no oneelse.

FIG. 91B shows example steps for receiving an item. Intended recipient4056 may receive delivery of the document by walking up to the same ordifferent electronic appliance intelligent kiosk 600B and operatecontrols 4106 instructing the appliance to deliver the document to him(FIG. 91B, block 4092A). Depending upon the delivery options sender 4052selected, appliance 600 may require recipient 4056 to prove he is who hesays he is (FIG. 91B, block 4092B). For example, appliance 600B mayrequire recipient 4056 to provide a secret password and/or it mayrequire the recipient to insert a special card into card reader 108.This special card may certify the identity of recipient 4056. Appliance600B might also take the recipient's picture using camera 4124, andautomatically compare the picture with a known photographic image of therecipient to see if they match. Once appliance 600 is satisfiedregarding the identity of recipient 4056, it may require the recipientto pay (FIG. 91B, block 4092C)—such as for example in a “collect ondelivery” model. The appliance 600 may then open the secure electroniccontainer (“attachécase”) 302 and deliver the item it contains torecipient 4056 (FIG. 91B, block 4092D). For example, if the container302 contains item 4054, prints the copy of the document, and providesthe printed copy through document slot 4102. It could also giverecipient 4056 a digital copy of the item 4054 (such as a document) viamedia drive 4132 and/or port 4130. Appliance 600B may deliver thedigital copy of item 4054 within a container 302 and/or may protect theitem with seals, electronic fingerprints, watermarks and/or othervisible and/or hidden markings to provide a “virtual container” or someof the security or other characteristics of a container (for example,the ability to associate electronic controls with the item).

Example Electronic Delivery and Return Receipt

FIG. 92 illustrates one example delivery of item 4054 to recipient 4056.In this example, the virtual electronic delivery person 4060 demands tosee a certificate or token 4064 proving that recipient 4056 is the sameperson sender 4052 designated to receive item 4054 (FIG. 91B, block4092B). Recipient 4056 could provide this certificate 4064 by, forexample, supplying a “smart” electronic card containing the certificatein digital form. Alternatively or in addition, if sender 4052 sorequired, electronic delivery person 4060 might require stronger formsof personal authentication such as, for example, a voice print,fingerprint or handprint test, identification based on other physical(biometric) characteristics such as face profile, retinal or irispatterns of the eye, or the like.

There are advantages to using multiple authentication techniques incombination. For example, a well made certificate is essentiallyunforgeable (which is to say, it would be easier to fabricate aelectronic fingerprint carrying device, for example, than a well madecertificate 4064 barring unforeseen advances in mathematics), but thetrouble with certificates is the weakness of correlation betweenphysical access (e.g., holding the card, or sitting at the appliance)and permission to use. Passwords are a weak form of authentication—thatis, establishing this correlation. Biometric techniques, particularlyiris and retinal scans, are stronger forms of authentication. It ispossible for biometric information to be encoded in a field of acertificate 4064, and for the software controlling the card to confirmthat the biometric input is consistent with the field in the certificateprior to authorizing use of the certificate or the card in general. Thisauthentication may be limited in time (e.g., using an inactivity timeout, each time the card is inserted, etc.) In addition, a transactionmight require this authentication to occur simultaneous with use (ratherthan for an entire session, even if the card only requires oneauthentication per session).

After payment has been arranged (FIG. 91B, block 4092C), electronicdelivery person 4060 will open secure container 302 and give recipient4056 a printed and/or electronic copy of item 4054 only once he issatisfied—to the degree required by sender 4052—that the recipient 4056is the correct person.

Electronic delivery person 4060 may also note various information aboutthe delivery (illustrated here by having him write the information downon a clipboard 4066, but implemented in practice by electronicallystoring an “audit” trail). System 4050 may—based on the particularreceipt options sender 4052 requested—provide the sender with anelectronic and/or paper receipt of the type shown in FIG. 92A, forexample (FIG. 91B, step 4092D). Such an example receipt 4066 mightspecify, for example:

-   -   item and/or transaction number;    -   name of actual recipient 4056 to whom the item was delivered;    -   the company recipient 4056 works for;    -   day, date and time of day of delivery;    -   who actually opened and read or used an item 4054;    -   when (day, date and time of day) item 4054 was actually opened        and read, and    -   the public key of the trusted third party that issued the        digital certificate 4064 attesting to the identity of recipient        4056.

The sender's electronic appliance 600A and the recipient's electronicappliance 600B can report their respective “audit trails” periodicallyor upon completion of delivery or some other event. They can report theaudit information to a support facility such as information utilityusage analyst 200C (see FIG. 1A). Usage analyst 200C can work withreport creator 200D to issue a written or electronic report to sender4052. Alternatively, since electronic appliances 600A, 600B are secure,the electronic appliances can maintain copies of the audit trail(s) andproduce them in secure form on demand at a later date to evidence orprove that the document was sent and delivered (for example, so sender4052 can't deny she sent the item and recipient 4056 can't deny hereceived the item). The appliances 600A, 600B could store an entire copyof the item 4054, or they could instead store a “message digest” thatcould later be used to securely prove which item was sent.

Other Types of Electronic Appliances can be Used

As mentioned above, the kiosk appliances 600 shown in FIGS. 88 and 89are just one example of electronic appliances that can be used forsecure document delivery.

Secure electronic delivery can also be from one personal computer 4116to another. FIGS. 93-96 show that system 4050 can be used to deliverdocuments securely between various different kinds of electronicappliances—personal computers, for example.

FIG. 93 shows that electronic kiosk appliance 600A may send item 4054 toa different type of electronic appliance 600C such as a personalcomputer 4116 having a display 4120, a keyboard 4118 and a pointer 4122.Personal computer 4116 in this example is also provided with a secureprocessing unit 500 or software based HPE 655 (See FIG. 12) to providesecure, tamper-resistant trusted processing. In this example, kioskappliance 600A and personal computer appliance 600C are both part ofvirtual distribution environment 100 and are interoperable with oneanother in a secure fashion.

Secure delivery can also be from one personal computer 4116 to another.FIG. 94 shows a sender 4052 inputting item 4054 into an optical scanner4114 connected to a personal computer 4116′. Electronic delivery person4060 can deliver the electronic version of item 4054 within securecontainer attaché case 302 from personal computer 4116′ to anotherpersonal computer 4116 operated by recipient 4056.

FIG. 95 shows that the item 4054 delivered by electronic delivery person4060 need not ever exist in paper form. For example, sender 4052 mightinput digital information directly into personal computer 4116′ throughkeyboard 4118—or the item could originate from any other secure ornon-secure digital source. Sender 4052 may then cause electronicdelivery person 4060 to deliver this digital item 4054 to the recipient4056's personal computer 4116 for viewing on display 4120 and/orprinting on printer 4122. Item 4054 can also be inputted from and/oroutputted to a floppy diskette or other portable storage medium, ifdesired. As mentioned above, item 4054 can be any sort of digitalinformation such as, for example text, graphics, sound, multi-media,video, computer software. The electronic delivery functions can beprovided by software integrated with other software applications (e.g.,electronic mail or word processing) executing on personal computer 4116.

FIG. 96 shows an example in which multiple electronic appliances 600(1),. . . , 600(N), 600A and 600B communicate with a secure electronicdelivery computer “server” 4150 over a network 4152. For example,appliances 600(1), . . . , 600(N) may each be a personal computer orother workstation 4116. Appliance 600A may be, for example, a networkfacsimile device including a document scanner and document printer.Appliance 600B may be one or more additional “servers” of various types.Each of these various appliances 600 may use secure electronic deliveryserver 4150 to provide secure electronic item delivery and handlingservices. Server 4150 may include a secure processing unit 500 (PPE)interoperable with other VDE-capable electronic appliances, and maycommunicate with such other electronic appliances over a communicationslink 4154 such as the Internet or other electronic network. Each of theother appliances 600 may also include an SPU 500 (PPE) if desired toprovide security and interoperability with other VDE-capable devicesover network 4152.

Electronic Execution of a Legal Document

FIG. 97 shows that trusted delivery system 4050 can also be used toelectronically execute a legal contract 4068. In many cases it may bevery inconvenient for the parties 4070A, 470B to a legal contract 4068to meet face-to-face and physically sign the contract. For example, oneof the contracting parties may be geographically distant from the other.It may nevertheless be important for the contract 4068 to be finalizedand executed rapidly, reliably and in a manner that cannot be repudiatedby either party.

System 4050 supports “simultaneous” as well as non-simultaneous contractor other document execution among contracting parties 4070. Simultaneouscompletion allows multiple parties located in physically differentlocations to directly and simultaneously participate in the execution oflegal documents and/or other transactions that require authorizations.

Currently, businesses often prefer simultaneous execution of documentsat what is called a “closing.” Such closings for important documentsfrequently require the presence of all participants at the same locationto simultaneously sign all necessary legal documents. Businessexecutives are often reluctant to sign a set of documents and then sendthem to the next party to sign, since special legal language may berequired to release the first (or early) signing party if the documentsare not quickly signed by other participants and since certainliabilities may exist during this interim period.

FIG. 97 shows an example in which two contracting parties 4070A, 4070Beach simultaneously sit down in front of an electronic appliance 600such as a personal computer or intelligent electronic kiosk. Each of thecontracting parties 4070 may be required to securely identify themselvesby, for example, inserting a card 4109 into a card reader 4108 and/or byallowing a biometric sensor 4124 to scan a part of their body such as afinger print or a retina pattern—thereby proving that they are who theysay they are.

One relatively weak form of authentication is physical possession of thecard 4109. Nonetheless, if some form of weak authentication is used andbiometric information is gathered in real time by sensor 4124, it may becorrelated with some trusted record stored elsewhere, and/or deliveredalong with the item 4054. If biometric information is codelivered withthe item 4054, and it is ever actually used, it must be correlated witha trusted record (this trusted record could, for example, be generatedby the person providing biometric data in the presence of a trustedparty if the validity of a transaction is called into question, at thesacrifice of significant automation and “commercial confidence”benefits). The ability to establish trust as the transaction occurs,rather than having some degree of nonrepudiation later (imagine if thetransaction were fraudulent, and a user relied on the person showing upto give a retinal scan) is one significant benefit of example system4050.

If the parties are simultaneously at their respective electronicappliances 600, they may verify each other's identity using videocameras and screens built into the kiosk. Such simultaneous executionhas the advantage of allowing multiple parties at different physicallocations to negotiate a deal in real time and then simultaneously,reliably execute and receive final, signed agreement copies that arevalid and legally binding.

Trusted delivery mechanism 4060 may send messages such as offers 4054Aand acceptances 4054B between the two electronic appliances 600A, 600B.These messages may be packaged within secure electronic containers 302.Some of these may be human readable, others may be automated as in FIGS.76A and 76B. If they are human readable and operator managed duringnegotiation, they may represent a user interface aspect of controlstructures (e.g., see load module DTD description in connection withFIG. 23, and pop up user interface usage in connection with FIG. 72C).

Once the parties 4070A, 4070B agree on the terms of the contract, theymay securely indicate their agreement and system 4050 can generate anelectronic and/or paper contract document 4068 that evidences andmemorializes the agreement. As will be discussed below, contractdocument 4068 may have special attributes such as seals 4200,hand-written signatures 4300 and/or visual or hidden “electronicfingerprint” information 4400. Such seals 4200, signatures 4300 andelectronic fingerprints 4400 can be used to establish the authenticityof the document (for example, preventing a signatory from repudiating itand to allowing it to be admitted as evidence in a court of law).

FIG. 98 shows that system 4050 can be used to electronically formcontract 4068 between any number of different parties. Electronicnetwork 4058 might, for example, be a world-wide electronic highway 108or other network such as the Internet, with the various parties beinglocated in many different locations around the world. Alternatively,electronic network 4058 might be a private data network within anorganization—or it might be a mixture of the two. Different contractingparties 4070 may use different kinds of electronic appliances 600 suchas, for example, personal computers, intelligent walk-up kiosks, hometelevision sets, or any other type of electronic appliance capable ofsecurely receiving and providing information about contract 4068.

System 4050 can electronically pass contract 4068 along a “chain” fromone party 4070 to the next (“Round Robin”), collecting signatures as ittravels along. System 4050 can also allow each party 4070A-4070F tocommunicate with any other party. One copy of contract 4068 could bepassed along from party to party and iteratively signed at therespective signers' locations. The last signer could then broadcastfinal, signed copies of contract 4068 to all parties. The electroniccontainers 302 can specify who the next recipient of contract is—forminga trusted chain of handling and control for contract 4068.

In one example, all of the parties 4070 may be required to hit an “IAgree” button (e.g., by placing a finger onto a biometric sender 4124shown in FIG. 97, “clicking” on a displayed “I agree” icon, etc.) beforethis transaction is actually carried out. Then, barring a systemfailure, the execution is effectively simultaneous, since it isn'tinitiated until everyone has indicated their approval, and won't becompleted unless each system performs correctly.

Trusted Electronic Go-Between

FIG. 99 shows that system 4050 may introduce a trusted electronic“go-between” or intermediary 4700 between the sender 4052 and recipient4056 (and/or between two or more contracting parties 4070). Trustedgo-between 4700 acts as an impartial overseer who can document atransaction, and may also become actively involved in directing thetransaction to see to it that it is completed properly. Trustedelectronic go-between 4700 may provide valuable third party servicessuch as, for example:

-   -   maintaining a secure archive of data, receipts and other        information about transmissions senders 4052 sends to recipients        4056;    -   managing the transaction for example, so that not all parties        need to participate simultaneously or to ensure that all        prerequisites or preconditions have been satisfied);    -   making certain certifications about information sent via system        4050 such as acting as a digital witness by notarizing documents        and transmissions.

The drawings show the trusted go-between 4700 as a person for purposesof illustration only. In the preferred example, trusted go-between 4700may be a computer that performs its functions electronically in a highlyautomatic and efficient way. In one example, the computer's capabilitiesmay be augmented by human participation.

FIG. 100 shows one example use of a trusted electronic go-between 4700to assist in delivering an item such as document 4054 from sender 4052to recipient 4056. In this example, sender 4052 may send the item 4054directly to recipient 4056 within one or more secure electroniccontainers 302. Alternatively, sender 4052 can send item 4054 (or a copyof it) to trusted electronic go-between 4700 within a secure electroniccontainer 302A. When the trusted electronic go-between 4700 receivescontainer 302A, she may be authorized to open the container, remove item4054 and affix her seal 4200 to the document. Seal 4200 may certify,notarize and/or “date stamp” the item 4054 as having been received andseen by trusted electronic go-between 4700 on a certain day at a certaintime. Trusted electronic go-between 4700 may keep a copy of item 4054within a secure electronic library or archive 4702 _([BW1]). Inaddition, if desired, trusted electronic go-between 4700 may deliver acopy of item 4054 with the affixed seal 4200 to recipient 4056. Whenrecipient 4056 opens the secure electronic container 302B, he willnotice the seal 4200 and have confidence that it is the same item 4054that was seen and archived by the trusted electronic go-between 4700. Inthis example, recipient 4056 may directly provide a return receipt 4066within an additional secure electronic container 302C—or trustedelectronic go-between 4700 can provide such a return receipt to sender4052 based on audit information provided by recipient 4056 and/ororiginated by the trusted go-between.

The Trusted Electronic Go-Between can Help with Contracts

FIG. 101 shows how trusted electronic go-between 4700 can make it easierfor parties 4070 to execute a legal contract 4068. In this example, thetrusted electronic go-between 4700 can maintain a requirements list4704. This requirements list 4704 (an example of which is shown in FIG.101A) may specify all of the steps that must be completed and all of theconditions that must be satisfied in order to execute legal contract4068. Trusted electronic go-between 4700 can monitor the electroniccommunications between the contractual parties 4070A, 4070B, and notifythem of additional requirements that need to be met before the contract4068 can be signed.

In one example, trusted electronic go-between 4700 can also act as amediator to resolve disputes between the contracting parties 4070A,4070B, and can help negotiate the contract. At the conclusion of thecontracting process, trusted electronic go-between 4700 may affix itsown seal 4200A to the executed contract document 4068. This seal 4200Amay provide a guarantee or assurance that all of the steps required bytrusted electronic go-between 4700 were fulfilled before the contract4068 was executed and that the contracting parties 4070A, 4070B are whothey say they are and had authorization to execute the contract.

FIG. 101B shows how the trusted electronic go-between 4700 could be thefocal point for a contractual relationship between a number of differentcontracting parties. In this example, trusted electronic go-between 4700might communicate directly with each of the various contracting parties4070 via electronic digital messages, and create the resulting executedcontract based on these communications. In one example, go-between 4700doesn't tell any participant 4070 who has already agreed and who hasn't.The SPU's 500 (PPEs) of each party's appliance 600 can receiveadministrative objects (see FIG. 21) with the information about eachapproval, yet this information does not need to be released outside theSPU (PPE). In this model, the rules associated with affixing electronicsignatures (digital and/or an image of a physical signature) can beestablished at the beginning of the negotiation to indicate the list ofparties 4070 that must agree. Then, as each party 4070 agrees, theirelectronic appliance SPU 500 (PPE) will send administrative objects toeach of the other participants containing one or more events and dataassociated with those events that can be processed by the controlsassociated with use of their signature. If the administrative objectsomit the creator identity public header 804 information (see FIG. 17),and the information is transmitted via a remailer (or otherintermediary) when network addresses could be used to identify a sender,there will be no way to determine the identity of the sender outside theSPU (PPE) 500. As soon as all of the conditions for use of the signaturehave been fulfilled, and an event is presented to sign the document, therest of the transaction can go forward.

It is extremely useful to have trusted go-between 4700 monitoring thisactivity to order the application of signatures (if required), and toallow a roll back if the system fails before applying all of thesignatures. The role of go-between 4700 may, in some circumstances, beplayed by one of the participant's SPU's 500 (PPEs), since SPU (PPE)behavior is not under the user's control, but rather can be under thecontrol of rules and controls provided by one or more other partiesother than the user (although in many instances the user can contributehis or her own controls to operate in combination with controlscontributed by other parties). In another example, the go-between role4700 may comprise a “virtual go-between” comprised of a one, acombination of plural, or all, nodes of participants in a collective orother group. Governance can be shared through the interaction of rulesand controls of the various node PPEs producing a go-between controlrole. Upon the completion of a go-between managed transaction,transaction audit information for archive, billing, security, and/oradministrative purposes may be securely transmitted, directly, orthrough one or more other participating in the virtual go-between.

The Secure Electronic Go-Between can be Used within and BetweenOrganizations

FIG. 102 shows an example use of system 4050 for inter- andintra-organizational communications. FIG. 102 shows an organization A(left-hand side of the drawing) as having an “Intranet” (a private datanetwork within a particular organization) 5100(A). Intranet 5100(A) maybe a local and/or wide area network for example. User nodes 600(A)(1), .. . , 600(A)(N) (for example, employees of organization A) maycommunicate with one another over Intranet 5100(A).

FIG. 102 also shows another organization B that may have its ownIntranet 5100(B), user nodes 600(B)(1), . . . , 600(B)(N), and privatetrusted go-between 4700(B). In addition, FIG. 102 shows a public datanetwork 5104 (such as the Internet for example) and a public trustedgo-between 4700(C). FIG. 102 shows that in this example, organizations Aand B communicate with the outside world through trusted go-between4700(A), 4700(B) (which may, if desired, also include “gateways”,“firewalls” and other associated secure communications components). Inother examples, trusted go-between 4700(A), 4700(B) need not be theactual “gateway” and “firewall” to/from Internet 5104, but could insteadoperate wholly internally to the respective organizations A, B whilepotentially generating electronic containers 302 for transmission overInternet 5104.

In this example, organization A user nodes 600(A)(1), . . . , 600(A)(N)each have an instance of a virtual distribution environment protectedprocessing environment, and can communicate with one another overIntranet 5100(A) via secure electronic containers 302. Similarly,organization A user nodes 600(B)(1), . . . 600(B)(N) each have aninstance of a virtual distribution environment protected processingenvironment, and can communicate with one another over Intranet 5100(B)via secure electronic containers 302. In addition, organization A andorganization B can communicate with one another over Internet 5104 viasecure electronic containers 302.

Organization A's private trusted go-between 4700(A) may be used forfacilitating organization A's internal communications and processes.Private trusted go-between 4700(A) might be used, for example, tocarefully track documents and other items sent from one user to anotherwithin organization A. The public go-between 4700(C), meanwhile, can beused to coordinate between organization A and organization B without,for example, revealing confidential information of either organizationto the other organization. Below are more detailed examples of how theFIG. 102 arrangement might be advantageously used to conduct businesstransactions.

More about the Secure Electronic Container

FIG. 103 shows an example secure electronic object 300 and its contents.Once again, although object 300 is shown as a locked attaché case forillustration purposes, the object and its associated container 302 istypically electronic rather than physical and may provide security,trustedness and confidentiality through use of strong cryptographictechniques as shown in FIGS. 5A, 5B and 17-26B.

In this example, secure container 302 may contain a digital image 4068Iof a document or other item 4054 to be delivered from one party toanother. This image may include one or more seals 4200, one or morehand-written signatures 4300, and one or more electronic fingerprints4400. The item 4054 may be multiple pages long or it may be a singlepage. The item 4054 may contain text, pictures or graphical information,computer instructions, audio data, computer data, or any combination ofthese, for example. Image 4068I may be represented in a so-called“universal” format to allow it to be created and displayed and/orprinted by any standard software application capable of processing itemsin the appropriate “universal” format. If desired, image 4068I mayinclude cover sheets, virtual “stick on” notes, and/or the like. Securecontainer 302 may contain any number of different 4054.

Container 302 may also contain another, data version 4068D of the item4054. This data version 4068D might, for example, comprise one or more“word processing” files corresponding to a text document, for example.

The container 302 may also contain one or more tools 4074 for usingimage 4068I and/or data 4068D. Tools 4074 might be used to allow theintended recipient 4056 to manipulate or view the image 4068I and/or thedata 4068D. Tools 4074 might be computer programs in one example (asmentioned above, item 4054 can also be a computer program such as aprogram being sold to the recipient).

Secure container 302 may also contain an electronic, digital controlstructure 4078. This control structure 4078 (which could also bedelivered independently in another container 302 different from the onecarrying the image 4068I and/or the data 4068D) may contain importantinformation controlling use of container 302. For example, controls 4078may specify who can open container 302 and under what conditions thecontainer can be opened. Controls 4078 might also specify who, ifanyone, object 300 can be passed on to. As another example, controls4078 might specify restrictions on how the image 4068I and/or data 4068Dcan be used (e.g., to allow the recipient to view but not change theimage and/or data as one example). The detailed nature of controlstructure 4078 is described in connection, for example, with FIGS.11D-11J; FIG. 15; FIGS. 17-26B; and FIGS. 41A-61.

Secure container 302 may also include one or more routing slips 4072 andone or more audit trails 4077. Routing slip 4072 and audit trail 4076are data structures defined by and/or associated with electroniccontrols 4078, and may be integrated as part of these electroniccontrols (see FIGS. 22-26B for example). Routing slip 4072 might be usedto electronically route the object 300 to the intended recipient(s) 4056and to specify other information associated with how the object 300 isto be delivered and/or handled. Audit trail records 4077 may be used togather and recover all sorts of information about what has happened toobject 300 and its contents (e.g., where container 302 has been, howimage 4068I has been used, etc.). Audit trail 4077 may be used, forexample, to generate a return receipt as shown in FIG. 92A. Routing slip4072 and/or audit trail records 4077 (and associated controls 4078)don't have to be delivered within the same container 302 that containsthe image 4068I and/or the data 4077—they can be delivered independentlyin another container 302 if desired.

Document Signatures

FIG. 104 shows some examples of how system 4050 can “sign” printed item4054. In most modern societies, a person indicates his or her assent toa legal document by affixing his or her hand-written signature and/orseal. In the United States, for example, the act of hand writing one'ssignature on a document may legally bind the signer to the terms andconditions set forth in the document. In other countries (notablyJapan), a person indicates assent and agreement to be legally bound byimprinting the document with a special stamp unique to that person. Acorporation may emboss legal documents with its corporate seal toindicate the corporation's assent to the document contents. Governmentalauthorities in many countries use official seals to certify that thedocument is an official one.

System 4050 in this example can accommodate any or all of theseconventions by imprinting various graphics and/or symbols on printeditem 4054. In the FIG. 104 example, item 4054 bears a “hand-written”signature 4300, a seal 4200, and a electronic fingerprint 4400 (that inone example may comprise a “hidden signature”).

Hand-written signature 4300 may be a graphical image of the signer's ownhand-written signature. System 4050 can obtain this hand-writtensignature image 4300 in a number of ways. For example, system 4050 mayrequire the signer to sign his or her signature at the time item 4054 iscreated. In this example, once the document is finalized, sender 4052 orcontracting party 4070 can sign his or her signature using a magnetic orpressure-sensitive signature capture device, for example. Suchconventional signature capture devices electronically capture the imageof a person's signature and store it in a memory. System 4050 canthen—once it securely obtains the authorization of the signer with avery high degree of trustedness and sureness (e.g., by requesting apassword, biometric test, etc.)—place hand-written signature 4300 ontoan appropriate part of item 4054.

Alternatively, the signer may carry his or her hand-written signature ona portable storage medium such as, for example, a magnetic, smart ormemory card. The portable storage unit may employ rules and controls forbudgeting the number of times and/or class and/or other circumstances ofa transaction that a signature can be employed, or before the deviceneeds to re-connect to a remote authority as disclosed in theabove-referenced Shear et al. patent. The signer can present thisstorage medium to system 4050 as a source for the signature image 4300shown in FIG. 104. Once system runs certain checks to ensure that thesigner is in fact the one who has presented the signature card, thesystem can securely read the signer's hand-written signature from themedium and place it on to item 4054.

In still another example, system 4050 may securely maintain hand-writtensignature files for a number of different users in a secure archive or“secure directory services” as disclosed in the above-referenced Shearet al. patent disclosure. At a user's request, system 4050 may call upthe signature file pertaining to that user and impress the correspondingsignature onto item 4054. If an image representation of a signature isstored on portable media or in a directory service, the image may bestored in an electronic container 302. Such a container 302 permits theowner of the signature to specify control information that governs howthe signature image may be used. In addition, or alternatively, thesignature image may be stored in or securely associated with a field ofa digital certificate (that may, for example, also incorporate otheridentifying information).

FIG. 104 also shows a “electronic fingerprint” 4400. Electronicfingerprint 4400 may be used to indicate the signer's name and otherinformation (such as, for example, the date and time of the transaction,the signer's public key, etc.) within the item 4054 contents in the waythat makes it difficult to remove the information. A term derived fromGreek roots, “steganography” which means “hidden writing”—applies tosuch techniques that can be used to hide such information within adocument while allowing it to be recovered later. Example techniques forhiding information from within text include, for example, varying thespacing between lines of text by an almost imperceptible amount toencode information (see FIG. 105A), varying by very slight amounts thespacings (“kerning”) between words or characters (see FIG. 105B). System4050 can use such “steganography” techniques to hide information withinan item 4054 (e.g., by slightly permuting the gray scale or colorfrequencies across a document) so it can be later recovered and used toauthenticate and/or identify the document—and/or it can use visibleelectronic fingerprinting or watermarking techniques to provide visibleindications of such information (see FIG. 105C).

System 4050 also is capable of imprinting special seals 4200 onto item4054. FIGS. 106A-106C show example seals 4200. Seal 4200A shown in FIG.106A may be the type of seal one expects from a Governmental documentbearing an official seal. While it is possible for system 4050 toprovide an embosser creating a raised seal 4200A, in a preferredembodiment system 4050 prints seals 4200A using a conventionalmonochrome or color printer at high resolution so that the seal image isflat. FIG. 106B shows an example rectangular seal 4200B in the center ofthe left margin of an item 4054, and another circular seal 4200C (forexample, of the type that might be used in Japan) in the lower left handcorner of the document. FIG. 106C shows an item 4054 bearing twocircular seals: one seal 4200D in the lower left hand corner of thepage, and another circular seal 4200E in the lower right hand corner.FIGS. 106A-106C are merely illustrative examples—any desired quantity,shape or configuration of seals or other visual, machine-readable codescan be used depending upon the prevailing legal climate, the country andaesthetic considerations.

FIGS. 107A and 107B show one example configuration for seal 4200. Inthis example, seal 4200 may include a center portion 4202, an outerportion 4204 and a border 4206. Center portion 4202 may bear adistinctive image to make the seal immediately recognizable. In thisexample, center portion 4202 is the great seal of the United States—andwould thus be appropriate for affixing on U.S. Government officialdocuments. Other appropriate images for seals might include, forexample, a family coat of arms, a printed or holographic photographimage of the signer, a predetermined complicated pattern, or the like.Besides being distinctive, the image 4203 within center portion 4202should preferable be complex and difficult to copy—making seal 4200 lessprone to counterfeiting. Similarly, border 4206 may be an ornate patternthat might show discontinuities if printed or copied using inferiorequipment.

In this example, outer portion 4204 is used for encoding digitalinformation. FIG. 107A shows an example “template” seal before thisadditional encoding information is added. FIG. 107B shows an example ofa completed seal in which many small lines have been added to at leastportions of the outer ring 4204 of the seal 4200. Appliance 600 could“complete” the FIG. 107A template seal to create a completed seal shownin FIG. 107B based on one or more electronic controls 4078. FIG. 107Balso shows a close-up view illustrating that the line pattern can havevariations that encode digital “bits” of information. In this particularexample, lines 4208 radiating outwardly from center portion 4202 mayencode a digital “1” value, while lines 4210 radiating inwardly fromborder 4206 may encode a digital “0” value. As another example, theselective use of large dots 4211 a, small dots 4211 b and no dots 4211 ccould encode digital values. Any kind of information (e.g., numerical,text, graphics, sound, or any combination of these) may be encoded intothe image of seal 4200 using this technique. The particular line imagesshown in FIG. 102B are illustrative only—other visual patterns (and/orsteganographic techniques) may be used to encode digital informationinto the seal's image.

System 4050 can recover the encoded information by scanning andanalyzing an image of item 4054 in either digital or printed form. Inone embodiment, system 4050 can create electronic controls 4078 based atleast in part on this information it obtains from seal 4200.

FIG. 108 shows one example of the type of “digital signature”information that might be encoded into the seal 4200's image. In thisparticular example, the text and/or graphics contents of item 4054 canbe transformed into a compact value using a special cryptographicfunction called a “one-way hash” 4212. The resulting number may be“concatenated” (i.e., put end to end) with other information such as,for example, a time value and a certificate value or number obtainedfrom a “digital certificate” 4214. The time value may be obtained from areal time clock 528 incorporated in secure processing unit (SPU) 500shown in FIG. 9. The resulting string of digital information may then beencrypted with the private cryptographic key of sender 4052, thecontracting party 4070 and/or system 4050. The resulting digitalsignature value 4216 may be used to encode some or all of the seal4200's pattern.

The hash function may operate on a document in its image form, or itstext equivalent (producing two different hash values). In addition, thetext version of a document may be pre-processed before operation of thehash function to simplify verification of a document if it must berekeyed into a verification system (e.g., in the case where allelectronic copies of a document have been lost). Since cryptographicallystrong hash functions are extremely sensitive to the slightest change indata (yielding different values if, for example, a tab character iskeyed as a series of spaces) this pre-processing may normalize thedocument by, for example, discarding all font and formatting informationand/or reducing each occurrence of “whitespace” (e.g., spaces, tabs,carriage returns, etc.) into a single space. If the same pre-processingis applied to a retyped version of the document before the hash functionis applied, it will have a much higher likelihood of yielding the samehash value if the documents are substantively the same.

System 4050 may later recover this information by digitally and/oroptically scanning the image of item 4054 and analyzing the pattern ofseal 4200 to recover digital signature 4216. System 4050 may then applythe public key corresponding to the private key used to encrypt theinformation—thereby recovering the hash, time and digital certificate,while at the same time authenticating the information as having beenencrypted with the relevant private key(s). In this example, System 4050also has the original document image 4054 available to it, and maytherefore duplicate the one-way hash process 4212 and compare the hashvalue it gets with the hash value encoded within seal 4200. Mismatchesindicate that the seal 4200 may have been copied from another documentand does not apply to the document currently being analyzed.

Other types of digital identifying information that system 4050 mightaffix to the document include, for example:

-   -   digital information generated by algorithms (such as error        correcting algorithms for example) including certain kinds of        unique transmittal information or certain unique pseudo-randomly        generated codes that might be combined with transmittal        information and/or information representing transmittal content,        such that representation of such a collection of relevant        transmittal related information may uniquely and reliably        confirm that a given document (or other information) sent by        sender 4052 is actually the exact document sent; or    -   Reed-Solomon codes or other error correcting or other algorithms        relying on formalisms within abstract algebra for establishing a        correct sequence of bits; or    -   MD4 or other message digest algorithms employing, for example,        one-way hash algorithms that attempt to uniquely identify a        sequence of bits that is highly sensitive to content and        ordering of bits in a sequence.

Example Electronic Appliance

FIG. 109 shows an example detailed architecture for electronic appliance600. In this example, appliance 600 may include one or more processors4126 providing or supporting one or more “protected processingenvironments” (PPE) 650 (e.g., SPEs 503 and/or HPEs 544) shown in FIGS.6-12 and 62-72). Protected processing environment 650 may, for example,be implemented using a secure processing unit (SPU) 500 of the typeshown in FIG. 9 and/or may be based on software tamper-resistancetechniques or a combination of software and hardware. As described abovein detail, protected processing environment 650 provides a secure,trusted environment for storing, manipulating, executing, modifying andotherwise processing secure information such as that provided in secureelectronic containers 302. In this particular example, secure containers302 may not be opened except within a protected processing environment650. Protected processing environment 650 is provided with thecryptographic and other information it needs to open and manipulatesecure containers 302, and is tamper resistant so that an attackercannot easily obtain and use this necessary information.

Electronic appliance 600 may be any type of electronic device such as apersonal computer, intelligent kiosk, set top box, or dedicatedstand-alone communications appliance—just to name a few examples.Processor 4126 is connected to

-   -   one or more user input devices 4106, 4118, 4140;    -   card/media reader 4108, 4132;    -   document reader/scanner 4114;    -   biometric sensor(s) 4124;    -   display 4104;    -   document printer 4122; and,    -   optionally, a receipt printer 4122A for printing receipts of the        type shown in FIG. 92A.

A document handler/destroyer 4115 may be provided to feed multi-pagedocuments into document reader/scanner 4114 and—in one embodiment—todestroy documents to ensure that only one “original” exists at a time.Such controlled document destruction might, for example, be useful inallowing sender 4052 to deliver an original stock certificate to atransfer agent. The sender 4052 could insert the original certificateinto appliance 600—which may scan the original to convert it to digitalinformation (e.g., through use of OCR technology), confirm delivery, andthen destroy the original paper version. Secure controls 4078 could beused to ensure that only a single original ever exists on paper.

Processor 4126 is also connected to secure and/or insecure digital orother storage 4130 (such as, for example, magnetic disks, random accessmemory, optical disks, etc.), and to a communications device 666permitting the processor to communicate electronically with otherprocessors or devices via an electronic network 4058 (672). In oneexample, appliance 600 may be provided with additional and/or differentcomponents such as shown in FIGS. 7 and 8.

Example Process to Send an Item

FIG. 110 shows example steps electronic appliance 600 may perform tosend an item such as item 4054. Initially, electronic appliance 600 mustbe created or established at the user site (or the user must go toelectronic appliance as shown in FIG. 88). This establishing process mayinclude, for example:

-   -   node initialization (FIGS. 64, 68, and 69), and updates (FIG.        65),    -   locally registering any rules and controls associated with the        user's rights,    -   locally registering any rules and controls associated with any        class-based rights, including, for example, any provision for        integration of the item sending process into a user application        (e.g., to be listed as a “printer” under a print set up in a        Windows or other personal computer software application); and    -   the establishment of any necessary certified user identities,        which may include, for example, the use of a wider purpose        certified identity and/or the certified use of a non-certified        identity (such as some network name service identifications) or        certified delegation of use of a certified identity.

Once the appliance 600 has been properly initialized, the first step ina send process 4500 may be to authenticate the identity of sender 4052(FIG. 110, block 4502). This authentication step 4502 may be performedin a variety of ways such as, for example:

-   -   use of biometric sensor 4124 to provide a retinal, iris,        fingerprint, thumbprint, or other scanning/matching;    -   the use of a voice print for identity verification;    -   hand-written signature capture and biometric analysis;    -   requiring the user to present an identification card 4109 (which        may be a smart card, magnetic card, or other storage        information) that contains information about the sender's        identity;    -   capture and pattern recognition of a photographic image of the        sender's face;    -   requiring the sender to respond orally and/or via other user        input devices 4106, 4118, such as keyboards or the like to        provide “secret” information such as Mother's maiden name,        special passwords or code words, or other information uniquely        known to the sender;    -   any combination or subcombination of these various techniques.

In this particular example, the authentication step 4502 may involve anapplication program executing on appliance 600 requesting authenticationsupport from protected processing environment 650—for example, sendingto the protected processing environment an authentication “event”requesting the protected processing environment to authenticate thesender and providing authentication information to the protectedprocessing environment (FIG. 110, block 4502) as a basis for theauthentication.

FIG. 111 shows example steps that protected processing environment 650may perform in response to receipt of an authentication event. Theexample steps shown in FIG. 111 are control set dependent—that is, thatare typically based on one or more electronic control sets previouslydelivered to the protected processing environment 650 during theregistration process described above.

In this particular example, the protected processing environment 650 mayexamine the authentication information provided to it (e.g., the outputof biometric sensors, password information, information read from anidentity card, etc.) and determine (based on methods provided in one ormore electronic control sets) whether it has sufficient basis toconclude with a requisite, specified degree of assurance that the senderis who she says she is (FIG. 111, decision block 4502A). Processesidentified within the control sets operating within the PPE 650 mayperform these functions using resources provided by the PPE—providing animportant degree of programmable, general purpose behavior.

The nature and characteristics of this sender authentication testperformed by PPE 650 may vary depending on the particular electroniccontrol set being used—as dictated by particular applications. Asdiscussed above, in situations that have legal significance in whichnon-repudiation is very important, PPE 650 may impose a relativelystringent authentication test. Other, more routine situations may usecontrol sets that impose less stringent authenticity checks.

The PPE 650 may abort the process if it decides there is insufficientinformation to form a trusted belief of authenticity and/or if itdetermines that the sender is not who she says she is (FIG. 111, block4502B). PPE 650 may indicate/authorize that the process may continue ifthe authenticity check is successful (FIG. 111, “Y” exit to decisionblock 4502).

The sender's appliance 600 may next need to identify or “register” theintended recipient(s) 4056 (FIG. 110, block 4506). In this particularexample, the step of registering the intended recipient(s) involvesgenerating a “register recipient” event and sending this event toprotected processing environment 650. Upon receiving this “registerrecipient” event, protected processing environment 650 may—based on oneor more methods within a corresponding electronic control set—performcertain steps required to coordinate its activities with the intendedrecipient's electronic appliance 600—including, for example, contactingthe intended recipient. Example steps are shown in FIG. 112.

Why might the sender's PPE 650 need to contact the recipient beforesending the item? The answer is that it may be necessary or desirablefor the sender 4052 and the recipient 4056 to negotiate and/or agree asto the appropriate electronic controls that should apply. In an itemtransmission scenario, for example, such an “agreement” might work outwho is going to pay for the delivery service, which recipient appliance(home or office) the document is to be delivered to, what kind of returnreceipt is acceptable to both parties, etc.

The PPE 650's “register recipient” event processing may, for example,allow the proposed recipient to deliver a set of controls to thesender's system that defines the parameters of receipt. Some generalpurpose systems may use the default settings in the kiosk or othertransmission station. The address itself may provide an indication tothe transmitting station as to whether it may or must request a set ofcontrol information from the recipient prior to transmission.

More complicated scenarios may require further coordination. Forexample, an option to destroy the original item at the send end andrecreate it at the recipient's end (e.g., in the case of the stockcertificate mentioned earlier) is both a send option and a receiptoption. Similarly, options pertaining to procedures for electroniccontract execution typically will require pre-agreement from both thesender and the recipient (i.e., from all parties to the contract). Inthese cases, there should be some menu options that are driven by theaddress of the proposed recipient—and there may be an electronic (orhumanly-driven) negotiation to resolve conflicts.

The PPE 650's “register recipient” processing may also require input orother interaction from the user. FIGS. 90A and 90B show a relativelystraightforward menu-based user interface that may be used to elicitinformation from sender 4052. In a more advanced example, DTDs 1108 (seeFIG. 23 and following) associated with one or more load modules 1100 maybe used to control user interfaces (e.g., the “pop up” as shown in FIGS.72A-72D)). In this model, the user interface does not contain anyspecific visual elements (e.g., menus, buttons, data entry fields,etc.). Instead, the pop up contains application “framework” code. Theframework code in this style of user interface uses a structured inputstream (DTD 1108) from the PPE 650 to create the visual elements of theinterface, and optionally the allowed values of certain fields. Thisstructured data stream may (like other control structure DTDs 1108) bebased on SGML, for example.

This dynamic user interface approach allows control structures to bemore “self describing” in the sense that application programs do notneed to know ahead of time (i.e. when they are written) all of thefields, values, etc. for the structures. This gives structure designersmore freedom in how their controls are designed. Given a rich enoughgrammar in the DTD 1108, designers needn't concern themselves withwhether application programs will have the ability to manage theinteraction with a user regarding their structures. This capability canalso be used to create controls that support the electronic negotiationprocess shown for example in FIGS. 76A-76B.

FIG. 112 shows example steps that may be performed by protectedprocessing environment 650, based on one or more electronic controlsets, in response to receipt of a “register recipient” event. In thisexample, PPE 650 first uses the dynamic user interaction discussed aboveto have the sender identify the proposed recipient(s) (FIG. 112, block4503). For example, PPE 650 may request sender 4052 to provide varioustypes of identification information corresponding to intendedrecipient(s) 4056 such as, for example, name; physical address;electronic address; public key; and the like. PPE 650 may check thisuser input for validity (decision block 4503A), and may abort theprocess (or perform some other exception handling routine) if the inputis not valid (e.g., it falls outside of the permissible scope as definedby associated electronic controls). PPE 650 may also, at this time—withor without input from sender 4052 as may be necessary—identify any otherinformation required for identifying recipients, such as for example,any preset template(s), class identification requirements, and/or otherautomation factors and/or workflow assignments, redistribution, and/orcontent interaction parameters.

The PPE 650 then may determine whether it needs to request and obtain acontrol set from the recipient to proceed (FIG. 112, decision block4506A). The PPE 650 may have obtained the required control set(s) duringa previous transaction, the sender may supply the required control set,or the PPE may in some cases be able to use a “default” control set italready has so that no additional control set might be required (“N”exit to decision block 4506A, FIG. 112)—and send processing may proceedto the next step.

On the other hand, if PPE 650 must get a recipient's control set (FIG.112, “Y” exit to decision block 4506A), the PPE 650 may contact theintended recipient's electronic appliance 600 and/or a control setarchive (FIG. 112, block 4506B) over network 672 for example. PPE 650may employ secure directory/name services as shown in FIG. 12 (and/or asdescribed in the above-reference Shear et al. patent disclosure) toobtain sufficient information for sending and addressing the item to theintended recipient(s) 4056.

Once PPE 650 determines how to contact the recipient, it may constructan administrative object 870 (see FIG. 21) requesting the appropriaterecipient controls (FIG. 112, block 4506C), and send the administrativeobject to the recipient's PPE 650 or other appropriate VDE node that cansupply the information (FIG. 112, block 4506D).

The PPE 650 within the recipient's electronic appliance 600 or otherresponding VDE node may process administrative object 870 upon receivingit (FIG. 112 block 4506E)—constructing a response (e.g., a responsiveadministrative object containing the requested or require control sets)(FIG. 112 block 4506G) and sending it to the sender's PPE 650.

The sender's PPE 650 may register the received controls (FIG. 112, block4506H) upon receiving them from the recipient's PPE 650. The sender'sPPE 650 may then determine, based on the received controls, whether itcan continue (FIG. 112, decision block 4506I). If there is a problemwith the controls (e.g., they are for some reason unacceptable to thesender, they are not valid, etc.), the sender's PPE 650 determineswhether the problem is critical (FIG. 112, decision block 4506J). If theproblem is critical, PPE 650 aborts the whole process (“Y” exit to FIG.112 decision block 4506J).

If the problem is not critical (“N” exit to FIG. 112 decision block4506J), PPE 650 performs an exception process (FIG. 112, decision block4506L) to handle the problem and then waits for the next event—which inthis particular example may be a “generate secure object” event (seeFIG. 110, block 4512). FIG. 113 shows example steps the PPE 650 mayperform in response to this “create secure object” event based on thecontrol sets registered in accordance with step 4506, for example.

Referring to FIG. 113, the PPE 650 may use the dynamic user interactiontechniques described above to request sender 4052 to select between sendoptions and to otherwise specify the type and level of service he or shedesires (FIG. 113 block 4512A; see FIG. 91A block 4090A). Generally,sender 4052 may be required to select between various options; eachoption may carry with it a certain price. The following are exampleoptions the sender 4052 may select from:

Document Options

Signature Options

-   -   a. digital    -   b. visual    -   c. both

Seal options

-   -   a. visual    -   b. hidden (steganographic)    -   c. both

Seal options

a. Insert third party seal

b. Complete sender seal

c. Provide handwritten signature

d. Provide steganographic electronic fingerprint

e. Provide visual electronic fingerprint

Privacy/Use Options

-   -   a. modify/no modify    -   b. partial disclosure

Item Destruction Option

-   -   a) destroy paper original    -   b) destroy digital “original”

Delivery Options

Receipt Options

-   -   a) receipt to send    -   b) receipt to sender and trusted go-between    -   c) receipt to trusted go-between    -   d) no receipt requested

Integrity Guarantee Options

-   -   a) no modifications permitted (final version, for example)    -   b) no modifications other than signing permitted    -   c) no cut, paste, exerpting permitted    -   d) other document (item) controls

Privacy Options

-   -   a) public transaction    -   b) authorization list    -   c) direct parties to transaction (sender, receiver, etc.)    -   d) direct parties plus transaction authorities (see Shear et        al.)

Authentication Options

-   -   a) type and/or “strength” of recipient authentications (e.g.,        biometric, password, other)    -   b) strength requirement

Delivery Type

-   -   a) direct delivery    -   b) store and forward    -   c) permit proxy delivery (registered or certified)

Contract Execution Options

send offer

-   -   a) single recipient    -   b) multiple recipients

send acceptance

propose modification

add comments

negotiate (with our without saving negotiation history)

execute contract

degree/type of non-repudiation evidence required

Teleconferencing Options

Name of party

Address of party (if known)

Secure directory lookup (if address unknown)

Quality (speed) of connection

Payment methods (if different for teleconference)

Advanced options

Teleconference protocol

Teleconference network carrier

Trusted Go-Between Options

Contract settlement options

Audit options

Archival options

-   -   a) archive digital “original”    -   b) archive “sent” audit record    -   c) archive “received” audit record    -   d) archive negotiation history audit record(s)

Notary options

-   -   a) notarize digital “original”    -   b) notarize sub-sections of digital “original”    -   c) notarize “sent” audit record    -   d) notarize “received” audit record    -   e) notarize negotiation history audit record(s)

Negotiations

-   -   a) Automated negotiations enabled (yes/no)    -   b) Specific human go-between (if yes, who)

Length of time to store records (days, months, years, forever)

Contents inaccessible to trusted-go-between (automated service only)

Payment methods

-   -   a) Mastercard    -   b) Visa    -   c) American Express    -   d) ACH    -   e) EDI X.12    -   f) other

In the dynamic user interface model, for example, the user optionsassociated with a contract offer (which are used to create electroniccontrols associated with the electronic transaction) might relate to asuggested addition, modification, deletion, etc. to an existing item4054. If the VDE-aware applications used by the participants includedword processing capabilities (given that the negotiation has a textbased portion), for example, the VDE protected content in the offercould be represented as a “redline” or “revision marking.” The controlscould further include aspects that manage modification of content in acontrolled way (e.g., see FIG. 51, and FIGS. 51 a-f). A more complexexample might include several of these modifications, insertions,deletions, etc. in a single offer to represent a “horse trading” offerindicating a willingness to make a series of changes at once, forexample, a willingness to pay more money in exchange for removing arestrictive clause.

The options (and associated controls) associated with a contractualoffer may also permit the offerer and/or the recipient to add commentsto the offer before it is sent and/or accepted. These comments and/orsome or all of the negotiation history may be recorded and managed usingthe audit capabilities of VDE and/or one or more repositories for VDEobjects.

In this example, the PPE 650 checks the user input for validity (FIG.113, decision block 4512B) based on applicable controls, and may abortthe process (or provide other suitable exception handling) if the inputis not valid.

PPE 650 may next specify any audit and routing controls based on theuser input it has received and/or the recipient controls it hasregistered (FIG. 113, block 4512C). As mentioned above, object 300 mayinclude one or more control sets 4073 (contained in one or more PERCs306 for example) that specify the type of routing and auditing to beperformed in connection with sending an item 4054 (and also providingone or more control methods for use in auditing and/or routing. Step4512C typically also involve creating electronic controls specifyingpermissions and/or restrictions relating to the use of item 4054. Infact, the electronic control set(s) 4078 created by block 4512C may, forexample, specify a variety of different document delivery or othercharacteristics such as, for example:

-   -   document delivery options selected by sender 4052;    -   authentication requirements applicable to intended recipient(s)        4056;    -   what use, if any, is to be made of a third part electronic        go-between 4700 and what the third party electronic go-between        is authorized to do and is restricted from doing;    -   other document flow requirements such as direct, pass through or        round robin (interactive);    -   applicable payment methods;    -   restrictions concerning use of the document (e.g., whether or        not the document can be modified, whether or not the document        can be passed along to another party, other restrictions        concerning document use and/or privacy); and    -   other item chain of handling and/or control restrictions.

Control set 4078 can be used to enforce a secure chain of handling andcontrol on document container 302 and/or its contents. This secure chainof handling and control may be used, for example, to specify delivery,routing, auditing or other parameters as discussed above.

In performing step 4512, appliance 600 may also create routing slip 4072(see FIG. 103) and a template for return receipt(s) 4066. In oneexample, items 4066, 4072, may be embodied within electronic control set4078 and expressed by the various elements within the electronic controlset. FIG. 113A shows an example of a routing slip 4072 data structurethat may be maintained within secure electronic container 302 (e.g., asone or more DTDs 1108 in connection with one or more load modules1100—see FIG. 23). This routing slip data structure 4072 may include,for example:

-   -   a transaction ID field 4520;    -   a sender ID field 4522;    -   a recipient 1 ID and node ID field 4524 (1), 4526 (1),        respectively, and a corresponding recipient receipt information        field 4527(1);    -   a recipient 2 ID and node ID field 4524 (2), 4526 (2),        respectively, and a corresponding recipient receipt information        field 4527(2);    -   a recipient N ID and node ID field 4524 (N), 4526 (N),        respectively, and a corresponding recipient receipt information        field 4527(N);    -   communication/routing information 4528;    -   exception list 4529; and/or    -   other information 4530.

Exception list 4529 may indicate “named exceptions” (e.g.,communications failure, line busy, refused receipt, refused paymentrequest, etc.) paired with a list of responses (e.g., try again, cancelentire transaction, send report, invoke event in PPE) and dataparameterizing the responses (e.g., number of retries, list ofrecipients of cancellation notices, report recipients, controlinformation identifier and additional parameters for control use and/orinvocation; respectively).

Recipient receipt information field 4527 for each recipient mayindicate, for example, the nature of the receipt required, and therecipients of that receipt. A receipt “template” may be included in thecontainer, may be referenced in an archive, or may be named out of a setof default templates stored in each appliance.

The routing slip 4072 (see FIG. 103) associated with the document(s) inthe container may be integrated with control information 4078 reflectingchain of handling and control relationships among recipients. Forexample, the control information 4078 associated with the item(s) 4054may be correlated with fields of the routing slip 4072. Successfulcompletion of a receipt may qualify a specific user to become eligibleto use a subset of the control information 4078 that permits them tomake changes in a portion of the item, and describe their own controlinformation for the changes, so long as this control information doesnot provide further recipients with the right to modify the newmaterial. The control information 4078 may further specify that nochanges may be made to an item 4054 until one or more specifiedrecipients has read the item, and (through use of reciprocal controls asshow in FIGS. 41 a-41 d for example) indicated their approval of furtherchanges.

In another example, an entire class of users may be permitted to accessthe documents (through the presence of a certificate indicating theirmembership in a class, for example), and the routing slip 4072 may beused to record who has handled a particular version of the document.Through use of chain of handling and control techniques, the presence ofcertain users on the routing slip may permit further control informationto be specified by a user. For example, after an analyst's researchreport has been reviewed by three other analysts, a manager may bepermitted to modify the control information associated with the reportto permit transmission to “public” users.

Electronic controls 4077 may also include one or more control methodsspecifying the type of audit information that is to be maintained inconnection with the electronic transaction. This audit information maybe used for constructing a receipt 4066, to provide evidence preventingrepudiation, and for a variety of other functions. Such auditinformation may be maintained exclusively within the sender's appliance600, it might be maintained exclusively within the recipient's appliancesecure database, it might be maintained exclusively within the trustedgo-between 4700's appliance 600 secure database, or it might bemaintained in a combination of any or all of these. Additionally, theaudit information may or may not be delivered with item 4054 dependingon the particular objectives. A usage clearinghouse 200 c as describedabove in connection with FIG. 1A and/or as disclosed in the Shear et al.patent disclosure may be used to track the audit information based onevent-driven or periodic reporting, for example. Audit records could betransmitted to a usage clearinghouse (or to a trusted go-between 4700)by an automatic call forwarding transmission, by a supplemental callduring transmission, by period update of audit information, by themaintenance of a constant communication line or open network pathway,etc.

FIG. 113B shows an example of secure audit information 4077 that may bemaintained under the control of one example set of electronic controls4078. This audit information may include, for example:

-   -   a transaction identifier 4532;    -   sender identifier 4534 identifying sender 4052;    -   an identifier 4536 identifying the location (e.g., node) of        sender 4052;    -   an identifier 4538 of recipient 4056;    -   an identifier 4540 specifying the location (e.g., node ID) of        the intended recipient 4056;    -   an identifier 4542 of the document or other item being sent;    -   a secure document descriptor (e.g., a one-way hash value        produced from the document's contents);    -   other document information 4546 (e.g., format and/or size);    -   document delivery options 4548;    -   cost/payment information 4550;    -   time/date the item the item was sent (field 4552);    -   time/date stamp 4554 of document receipt;    -   identification of who opened the document (field 4556);    -   a time stamp identifying the location/node date and time of        document opening (4558); and    -   other information 4560.

As mentioned above, audit information 4077 associated with use of adocument may be transmitted to many different parties. Audit information4077 may also be treated as part of the signaling methodology describedfor reciprocal methods (see FIGS. 41 a-41 d) to provide receipts. Forexample, copies of receipts may be delivered to the sender, as describedabove, as well as to the sender's manager in a corporate setting, or tothe sender's legal counsel or other professional advisors (such as taxadvisers, accountants, physicians, etc.) Some items 4054 which aredelivered to, or used by, recipients to gather information (such as taxforms, purchase orders, sales reports, and insurance claims) may requiredelivery of receipts to several parties other than the sender. Sometransactions may require the delivery of such receipts beforecompletion. For example, a sales report requesting delivery of productsfrom a company's inventory may require that a receipt from the readingof a document delivered to the sales organization be received by theaccounting department for audit purposes before permitting receipt ofthe document by the sales organization.

Referring once again to FIG. 113, electronic appliance 600 may nextrequest authority from sender 4052 to obtain payment for delivery of theitem (FIG. 110, block 4505; FIG. 113, block 4512D). Payment may be byany convenient mechanism, and may be made by the sender, the recipientand/or by a third party. This payment processing in this example ishandled by PPE 650 in accordance, for example, with one or more billingmethods as shown in FIG. 49D for example.

The appliance 600 is then ready to accept item 4054 (such as a document)to be sent if the item hasn't already been inputted (FIG. 110, block4507; FIG. 113 block 4512E). PPE 650 may (based on control setsspecifying this) use the dynamic user interaction technique describedabove to interact with the sender 4052 and obtain the requested item fortransmission. As mentioned above, for physical documents, appliance 600can optically scan the document into electronically readable formemploying document reader/scanner 4114 using page reader technologyand/or optical character recognition, for example. For electronicdocuments or other items such as those created by a personal computer4116 (see FIG. 95), this “inputting” step may be a matter of havingsender 4054 select or create the item using standard document or filecreation applications, or physically picking such document using iconsor other menu-driven techniques. In one particular example, sender 4052may “select” a document or item to send by commanding a word processingor other application to “print” or otherwise write the item to aparticular virtual printer or other output device which is mapped intothe overall secure electronic delivery process.

Appliance 600 may store the item in any of multiple representations. Forexample, it could store it in Adobe Acrobat (PDF) or other text basedpage description. Storing the document in CCIT Group III Facsimileformat is an example of a “universal” image format for black and whiteimages. Group V is an example of a color format. TIFF is another examplethat incorporates many image types, as well as different compressionformats and descriptive metadata.

PPE 650 may perform various tests on the inputted item and/or otherresults of the user interaction provided by block 4512E in accordancewith one or more user controls. For example, if the sender has specifiedthat he is sending a 6 page letter but only inputs five pages, PPE 650may notice this discrepancy and notify the sender (FIG. 113, decisionblock 4512F). PPE 650 may abort the process or perform other suitableexception handling (“N” exit to decision block 4512F) if the results ofthe test are not satisfactory.

PPE 650 may embed any seals 4200, signatures 4300 or hidden signatures4400 into the item if needed (FIG. 105, block 4510). This process mayinvolve, for example, identifying signature insertion locations andembedding signatures upon directed or other controlled circumstances.“Intelligent” optical character recognition (OCR) may be used toidentify signature locations. The display might also show an image ofthe page and allow the operator to identify the signature locations, forthemselves, or more importantly, for other parties. The PDF (or otherdocument description format) expressions could be extended to include acode that would allow indication of signature insertion points.

Depending upon the particular electronic controls being used, placementof the sender's signature or seal on the document may be based on thePPE 650's authentication of the sender as shown in FIG. 111—and mayrequire an additional indication of assent from the sender—for example,pressing a “Yes” button, providing additional biometric or otheridentification information (e.g., “place your finger on the sensor ifyou want to sign this letter” or “Provide your mother's maiden name tosign this letter”). Such authentication is important for non-repudiationand to prevent fraud. The sender might actually sign his signature on apressure-sensitive or magnetic-sensing signature capture and/orverification pad, provide a bit-map image of his signature by presentinga “smart card” storing it (plus using appropriate authenticationtechniques to assure that the bitmap image is being presented by thetrue signature owner), or provide enough information through userinteraction as described above that the PPE 650 can access an electronicsignature file containing the signature (e.g., stored locally withinappliance 600 or accessible over network 672 from an archive).

In the multi-party execution example shown in FIGS. 97 & 98, appliance600 could simultaneously embed two or more signatures into the samedocument or other item 4054—but only upon securely receiving indicationsthat all signatories assent to the document's terms.

Appliance 600 may next place the item and associated electronic controlsinto one or more secure containers 302 (FIG. 113, block 4512H).Referring to FIG. 103 once again, step 4512 normally involves placingthe image 4068I of item 4054 (including any seals, signatures and otherinformation) into the secure container 302. It may also involve placinga data (e.g., text) version of the item 4068D into the same or differentcontainer 302, along with possibly adding tools 4074 for using the itemin either or both forms. The PPE 650 may then send the completed object300 to an object switch 734 (see FIG. 12) for transmission to therecipient.

Referring to FIG. 110, appliance 600 may then deliver the securecontainer(s) 302 to the intended recipient 4056 and/or to trustedelectronic go-between 4700 based upon the instructions of sender 4052 asnow reflected in the electronic controls 4078 associated with the object300 (FIG. 110, block 4514). Such delivery is preferably by way ofelectronic network 4058 (672), but may be performed by any convenientelectronic means such as, for example, Internet, Electronic Mail orElectronic Mail Attachment, WEB Page Direct, Telephone, floppy disks,bar codes in a fax transmission, filled ovals on a form deliveredthrough physical mail, or any other electronic means to provide contactwith the intended recipient(s).

Appliance 600 may, through further interaction with PPE 650, immediatelyand/or later provide a receipt such as shown in FIG. 89A (FIG. 110,block 4516). Appliance 600 can immediately issue a receipt indicatingthat the object 300 has been sent. If rapid electronic communicationsmeans are being used, appliance 600 may also receive audit trailinformation from the recipient's appliance 600 while the sender waits,and issue a receipt indicating some or all of the kind of recipientinteraction information shown in the FIG. 92A example receipt. Thisreceipt providing step may, for example, be based on PPE 650 receivingone or more administrative or other objects 300 containing auditinformation (see FIG. 113B).

For purposes of security and trustedness, PPE 650 may actually “issue”the receipt—although it may use various other portions of appliance 600(e.g., receipt printer 4112A, display 4104, card/media reader 4108,4132, etc.) to output the receipt to the sender 4052. PPE 650 may alsoor alternatively maintain a copy of the receipt information (and/or theaudit information 4077 on which it is based) within its secure database610 (see FIG. 16). The trusted go-between 4700 similarly may maintain acopy of the receipt information (and/or the audit information 4077 onwhich it is based) within a secure electronic archive 4702.

Example Receive Process

FIGS. 114A and 114B show an example process 4600 for receiving an item.In this example, electronic appliance 600 that has received anelectronic object 300 may first generate a notification to PPE 650 thatthe container has arrived (FIG. 114A, block 4602). PPE 650 may, inresponse, use the dynamic user interaction techniques discussed above tointeract with and authenticate the recipient in accordance with theelectronic controls 4078 within the received object 300 (FIG. 114A block4603; authentication routine shown in FIG. 111).

Intended recipient 4056 may be given an option of accepting or decliningdelivery of the object (FIG. 114A, block 4604). If intended recipient4056 accepts the item, appliance may store the container 302 locally(FIG. 114A, block 4606) and then generate a “register object” event forprocessing by PPE 650.

FIG. 115 shows example steps that PPE 650 may perform in response to a“register object” event. In this particular example, PPE 650 maygenerate and send any return receipt to sender 4052, trusted electronicgo-between 4700, or other parties as required by the control set 4078within container 302 (FIG. 115, block 4607A)—by for example recordingaudit records 4077 and transmitting them within an administrativeobject(s) 870 to the required appliances 600. Appliance 600 may next, ifnecessary, obtain and locally register any methods, controls or otherinformation required to manipulate object 300 or its contents (FIG. 115,block 4607B; see registration method shown in FIGS. 43 a-d). Forexample, item 4054 may be delivered independently of an associatedcontrol set 4078, where the control set may only be partial, such thatappliance 600 may require additional controls from permissioning agent200 f (see FIG. 1A and “rights and permissions clearing house”description in the copending Shear et al. patent disclosure) or otherarchive in order to use the item.

PPE 650 may next securely authenticate the received item to ensure thatit is not a counterfeit (FIG. 115, block 4607C). For example, appliance600 may check one or more digital signatures 4076 within container 302to ensure that they are authentic, or perform other authentication testsas described in detail above. PPE 650 may perform critical and/ornon-critical exception processing (not shown) if the received object 300and its contents are not authentic.

PPE 600 may analyze any seal or other secure information that is part ofthe item 4054. For example, although the item image may be captured andcropped by untrusted processes, the analysis of the image data ispreferably done inside the PPE 650. Once the seal option of the image isidentified, an analysis process will be run to recover the digitalinformation stored in the seal (or steganographically encoded in thedocument). The next step is to determine what the expected values shouldbe. To do this, the PPE 650 may make requests of an application programrunning locally to determine a user's expectations, may use a digitalrepresentation of a receipt or other audit data, and/or may contact atrusted go-between or other trusted third party to obtain theappropriate expected values. To facilitate this process, there may besome unencrypted information in the seal that can be used to establish acorrelation with other information (e.g., a receipt, a transactionnumber, etc.). If such information is not available, a local store or atrusted third party might compare the entirety of the recovered digitalinformation with stored records to determine such a correlation. Inother cases, the expected values may be determined from context (e.g. adefault set of expected values; or by examining the seal informationitself, in either encrypted or decrypted form, for “tags” or otherschema or semantic information).

Once the expectation values of the information is determined, anyencrypted portion must be decrypted using the public key correspondingto the private key used above to make the seal. This key can be obtainedusing the mechanisms discussed in Ginter et al.

Once decrypted, the expected values may be compared with the actualvalues to determine correlation. Information about the correlation maybe reported to a user and/or a third party, as appropriate. In addition,some or all of the seal information may be included in such report.

Once PPE 650 is satisfied that the received item is authentic, it mayembed receipt related information into the item if the electroniccontrols 4078 associated with the item require it (FIG. 115, block4607D). In one example, the “electronic fingerprinting” techniquesdescribed above in connection with FIGS. 58B and 58C may be used forencoding various types of information onto item 4054—for example, toshow where the document has been. PPE 650 may embed seals 4200 and/orhidden information 4400 onto the item image 4068I at this time ifdesired. Electronic fingerprinting, sealing and embedding hiddeninformation may also be performed by the PPE 650 at the sender's 4052site—but, it may be advantageous to delay this process until the itemarrives at the recipient's site because more things have happened to theitem by then. For example, it may be desirable to encode, into seal4200, hidden information 4400 and/or hidden or unhidden electronicfingerprinting and/or watermarking information, the time stamp of whenthe recipient actually opened the container 302. In some arrangements,one seal, hidden signature or hidden or unhidden electronic fingerprintcould be added at the end of sender 4052, and an additional seal, pieceof hidden information and/or hidden or visible electronic fingerprintcould be added at the end of recipient 4056. Any or all of these varioustechniques may be used depending upon business requirements,convenience, logistics and aesthetics.

PPE 650 may next perform any required payment and/or other processing asneeded (FIG. 115, block 4607E). For example, PPE 650 may charge therecipient 4056 for receiving the document (e.g., “collect on delivery”)or it may perform other processing such as debiting, crediting,initiating a local audit, round robin pass along, or the like—all asspecified for example by electronic controls 4078.

Referring again to FIG. 114A, appliance 600 may next index or otherwisecatalog item 4054 for later access and reference (FIG. 114A, block4618), and may automatically identify document/file format for storageor presentation to recipient 4056 (FIG. 114A, block 4620). Appliance 600may then select any additional information necessary to allow therecipient 4056 to interact with the document (e.g., conduct anyassociated database searches or the like) (FIG. 114B, block 4622), andthen initiate any associated application(s) and any carrier applicationrequired to interact with the document/file (FIG. 114B, block 4624).Appliance 600 may then generate a “send” or “open” event to PPE 650requesting the PPE to open container 302 and allow the user to accessits contents.

FIG. 116 shows example steps that may be performed by PPE 650 inresponse to an “open” or “view” event. In this example, PPE 650 may—uponallowing recipient 4056 to actually interact with the item 4054—embedadditional recipient interaction related information into the documentsuch as, for example, the time the recipient actually looked at thedocument (FIG. 115, block 4625A). PPE 650 can at this time also sendadditional audit and/or return receipt information to the sender 4052indicating this event (FIG. 116, block 4625B) if the associatedelectronic controls 4078 require it. PPE 650 may then release the image4068I and/or the data 4068D to the application running on electronicappliance 600—electronic fingerprinting or watermarking the releasedcontent if appropriate (FIG. 116, block 4625C).

Referring again to FIG. 114B, appliance 600 may then wait for furtherinstructions from the recipient 4056. If the recipient wishes (and ispermitted by controls 4078) to print the item 4054 (FIG. 114B, decisionblock 4628), appliance 600 may send a “print” event to PPE 650. FIG. 117shows example steps PPE 650 may perform in response to such a “print”event. In this example, the PPE 650 may print the item using a suitableprinter 4122, including (if necessary or desirable) a certifying seal4200 and/or other markings on each page of the document (FIG. 117, block4630A).

If recipient 4056 wants to redistribute the item to another person (FIG.114B, decision block 4632), appliance 600 may generate a “distribute”event to PPE 650. FIG. 118 shows example steps PPE 650 may perform inresponse to such as “distribute” event. If the electronic control set4078 associated with the item 4054 permits redistribution, PPE 650 andappliance 600 may redistribute the item within a secure container(s) 302based on the conditions set forth in the applicable control set. Forexample, the control set may specify that item 4054 is to be “electronicfingerprinted” to indicate that recipient 4056 has received and lookedat it (FIG. 118, block 4634A). Other information that may be embeddedinto the document at this time could include, for example, informationrelated to the retransmittal such as, for example, name of sender(s),name of recipient(s), location of sender(s), location of recipient(s),employer(s) of sender(s) and/or recipient(s), and/or any otheridentifying information. PPE 650 may then package all requiredinformation within the same or different electronic container 302 andrelease the completed object(s) 300 to appliance 600 for transport usingelectronic or other communications means (FIG. 118, block 4634B). PPE650 may, if required by controls 4078, also send an administrativeobject 870 providing additional audit and/or receipt information to thesender 4052 indicating that the item has been passed on to the nextintended recipient(s) (FIG. 118, block 4634C).

Example Trusted Electronic Go-Between Detailed Architecture andOperation

In addition to the secure archive, witnessing and transaction managementfunctions discussed above, trusted electronic go-between 4700 mayperform additional services, such as, for example:

-   -   notary services;    -   provide an electronic trading environment allowing multiple        parties to electronically auction goods or services;    -   “clearing” transaction details, such as, payments, audit        information and the like;    -   acting as a “certifying authority” (see Shear et al. patent        disclosure) by issuing digital certificates 4064;    -   provide any or all of the various support and administrative        services described in the Shear et al. patent disclosure;    -   act as a trusted registry for electronic control sets;    -   provide electronic or human arbitration, mediation or        negotiation services to facilitate formation of agreements or        electronic contracts;    -   provide legal, accounting, architectural, design or other        professional services;    -   provide document assembly services;    -   provide document disassembly and component distribution        services;    -   provide real estate, commercial or other closing or settlement        services;    -   provide court document docketing, filing or other services to        assist a judiciary;    -   provide document registry certification, witnessing and other        services to assist a judge in ruling on the admissibility of        evidence in a court of law;    -   provide tax filing services including income tax form        preparation, payment handling and the like;    -   assist in communications between co-counsel, inside and outside        corporate counsel, and/or opposing counsel;    -   deliver highly confidential information critical to national        security interests;    -   international commerce and management of complicated        international commercial transactions;    -   stock and bond trading and/or brokerage;    -   managing and/or coordinating internal organizational functions        (e.g., corporate, government);    -   provide currency conversion and arbitrage services;    -   provide arbitrage services related to equity, bonds, options,        and other financial instruments    -   provide equity, bond, currency, options and other financial        instruments trading, authentication, non-repudiation, transfer        agent, and related administrative and/or support services;    -   creation, execution, interface with, and use of “smart agents”        as described in the co-pending Ginter et al., application (see        FIG. 73).

The trusted electronic go-between 4700 may comprise or include a“transaction authority” as disclosed in the above-referenced Shear etal. patent disclosure, and may have the same structure and architectureas shown in FIG. 55 et seq. of that co-pending application.

The trusted electronic go-between 4700 may be one computer or many. Itmay be centralized or distributed. It may be public or private. It maybe self-sufficient, or it may operate in conjunction with othergo-betweens or other support services. It may be entirely automatic, orit may include functions and tasks that must be performed using humanskills and expertise. It could be owned by a corporation or otherorganization, or it could be a cooperative. It could charge for itsservices, or it might offer its services free of charge.

As illustrated in FIGS. 119-120B, the trusted go-between 4700 may usereciprocal methods and distributed processing (see FIG. 41 a andfollowing) to perform its tasks. For example, the trusted go-between4700 could actually be a group of organizations (e.g., a “trustedgo-between” and a notary public) that each provide an aspect of theoverall function. For example, a certifying authority, a governmentalregulator, and an arbitrator could provide the trusted go-betweenfunction with the arbitrator acting as the “front end” (i.e. appearingas “the” trusted go-between from the participants' point of view).Alternatively, all three of these parties may each play a role asindependent trusted go-betweens (with the cost of more complex controlstructures, and all three parties requiring some level of coordinationby one or more of the other participants to the extent their functionsrelate to the same subject matter).

In another trusted go-between topology, each of the participants couldhave one or more trusted intermediaries that interact with each other onbehalf of the participants.

FIG. 119 shows an example architecture for a trusted go-between 4700that provides notarization functions. In this example, trustedgo-between 4700 may include an electronic appliance 600 providing one ormore protected processing environments 650 and a secure electronicarchive 4072. In this example, electronic appliance 600 may include aserver 4710 that communicates with protected processing environment 650and supports one or more administrative applications 4712. Server 4710may, in turn, communicate with additional electronic appliances 600Bincluding associated protected processing environments 650B.

In this specific example, additional electronic appliance 600B may beowned and/or operated by an entity having the legal authority to be anelectronic notary public. The notary public protected processingenvironment 650B may execute a control set 914B relating to notaryfunctions. Control set 914B in this example, has a reciprocalrelationship between an overall control set 914A executed by a protectedprocessing environment 650A of electronic appliance 600A. As shown inFIG. 120A, a notary protected processing environment 650B may originateboth parts of reciprocal control sets, and deliver one half 914A foroperation by appliance 600A—or electronic appliance 600A could originateboth parts and deliver part 914B to the notary electronic appliance600B.

The illustrated reciprocal control sets 914A, 914B may reciprocallyinteract as described above in connection with FIG. 41A-41D, forexample. FIG. 120B shows example reciprocal methods 1000 that might becontained within an example pair of reciprocal control sets 914A, 914B.In this specific example, the control set 914B operated by the notaryprotected processing environment 650B may include, for example, thefollowing methods 1000:

-   -   respond    -   initialize    -   request certificate    -   reply certificate    -   validate certificate    -   request “get document”    -   reply “get document”    -   calculate hash and other parameters    -   make seal    -   modify document    -   request “send document”    -   reply “send document”    -   store document into secure database 610.

Similarly, the reciprocal control set 914A operated by electronicappliance protected processing environment 650A may include methods 1000responding to reciprocal events, such as, for example:

-   -   request initialize    -   reply initialize    -   response certificate    -   response “get document”    -   response “send document”    -   additional reciprocal methods

The control sets 914B, 914A thus define and control the processing whichgo-between 4700 performs on documents and other items in order tonotarize them. Human users may interact with this process if desiredthrough optional user interfaces 4714, 4716. Such human intervention maybe required under certain circumstances (for example, if a live humanwitness might be required to testify as to certain notarization facts,if the automatic processes determine that a fraud is being attempted,etc.). The dynamic interface technology described above can provide amechanism for delivering a user interface through the system withoutdirect intervention by the provider of the overall service with respectto user interface, and by the notary with respect to the customerrelationship.

Example Trusted Go-Between Process Upon Item Receipt

FIG. 121 shows an example process 4750 that may be performed by atrusted electronic go-between 4700 in the FIG. 100 scenario shown above.In this example, the trusted electronic go-between 4700 receivesnotification that the electronic container 302 has arrived (FIG. 121,block 4752), may store the container locally (FIG. 121, block 4754), andopens and authenticates the container and its contents (FIG. 121, block4756). The trusted electronic go-between 4700 may then, if necessary,obtain and locally register any method/rules required to interact withsecure container 302 (FIG. 121, block 4758). The trusted electronicgo-between automatically accesses and identifies any controls indicatingprocessing options (FIG. 121, block 4759), and may generate any audittrails or other notification(s) that the container has arrived (FIG.121, block 4760). The trusted electronic go-between 4700 may thenoptionally archive the electronic container (and/or transmission relateddata) locally (FIG. 121, block 4761)—according to specific optionschosen by the sender or other participant and/or the default processingoptions of the trusted go-between (in one example, all containers andtheir contents may be stored for five years unless processing optionswere chosen to the contrary). The trusted electronic go-between 4700 mayperform further processes as required by associated electronic controls(FIG. 121, block 4764). The trusted electronic go-between 4700 may, ifnecessary, redistribute the container to the next recipient (FIG. 121,block 4766), and may then notify the sender 4052 or other parties of theactions taken (FIG. 121, block 4766).

Trusted electronic go-between 4700 may also archive transmission relateddata as determined by the electronic control set 4078 associated withthe item 4054 being sent, the transaction type and/or sender and/orrecipient information (FIG. 121, block 4760). For example, trustedelectronic go-between 4700 might automatically determine archivingrequirements based at least in part on certified class basedidentification information regarding sender 4052 and/or recipient 4056.In one example, trusted electronic go-between 4700 archives transmittalrelated information such as receipt data structure 4066 in an objectoriented database employing secure containers 302. It may also performdata reduction analysis and/or authentication processes (FIG. 121, block4762) to provide client specific, class and/or transaction type usageanalysis.

Trusted electronic go-between 4700 may next further process the receiveditem 4054 in accordance with requirements provided by electronic controlset 4078 (FIG. 121, block 4764). For example, the trusted electronicgo-between 4700 might perform an integrity check on the item, or it maynotarize the item before archiving it. Other processes that might beperformed by trusted electronic go-between 4700, depending on theparticular scenario, include for example the following non-exhaustivelist of functions and/or operations:

-   -   Applying signatures (digital, visual, or both)    -   Applying seals (visual, hidden, steganographic)    -   Inserting a third party seal    -   Completing a sender seal    -   Providing a handwritten signature    -   Providing a steganographic electronic fingerprint    -   Providing a visual electronic fingerprint    -   Determining Privacy/Use Controls (e.g., modify/no modify and/or        partial disclosure, recording public transactions, permitting        disclosure only to those on authorization lists)    -   Issuing receipts (e.g, to sender)        -   Integrity Guarantees (e.g., no modifications permitted, no            modifications other than signing permitted, no cut, paste,            excerpting permitted)    -   Contract execution functions such as:        -   send offer to single and/or multiple recipients,        -   send acceptance        -   propose modification        -   add comments        -   negotiate (with our without saving negotiation history)        -   execute contract        -   degree/type of non-repudiation evidence required        -   Teleconferencing options such as use of secure directory            lookup (if address unknown), quality (speed) of connection,            payment handling, and advanced options        -   Audit functions        -   Contract Settlement functions        -   Archival functions such as            -   archive digital “original”            -   archive “sent” audit record            -   archive “received” audit record            -   archive negotiation history audit record(s)            -   Length of time to store records (days, months, years,                forever)            -   Contents inaccessible to trusted-go-between (automated                service only)    -   Notary functions, for example:        -   notarize digital “original”        -   notarize sub-sections of digital “original”        -   notarize “sent” audit record        -   notarize “received” audit record        -   notarize negotiation history audit record(s)    -   Electronic negotiation functions, for example:        -   Automated negotiations enabled (yes/no)        -   Specific human go-between (if yes, who)    -   Payment handling, for example:        -   Mastercard        -   Visa        -   American Express        -   ACH        -   EDI X.12        -   other

As part of this processing, trusted electronic go-between 4700 may, ifnecessary, redistribute the electronic container 302 to the intendedrecipient 4056 (FIG. 121, block 4766).

Example Trusted Go-Between Process to Archive and Redistribute an Item

FIG. 122 shows an example process 4770 performed by trusted go-between4700 to archive and redistribute an item 4054. In this example process4770, the trusted go-between 4700 receives notification that an object300 (e.g., a container 302 containing an item(s) 4054) has arrived (FIG.122, block 4772). Trusted go-between 4700 may store the object 300 intoits secure archive 4702 (FIG. 122, block 4774). It may then open thecontainer 302 and authenticate its contents (FIG. 122 block 4776). Ifnecessary, trusted go-between 4700 may obtain and register any methods,rules and/or controls it needs to use or manipulate the object 300and/or its contents (FIG. 122 block 4778).

Unless it already has the required permission to redistribute the object300 (e.g., based on controls within the object's container 302), trustedgo-between 4700 may need to request permission to redistribute (FIG.122, block 4780). Trusted go-between 4770 may test to determine whetherit has the required permissions (FIG. 122, decision block 4782)—andrequest them from the appropriate party or parties if necessary.

If trusted go-between 4700 is unable to obtain the necessary additionalpermissions (“no” exit to decision block 4782, FIG. 122), the trustedgo-between may send a failure notification (FIG. 122, block 4784) andmay archive the requests, replies and audit records (FIG. 122, block4786). If, on the other hand, trusted go-between 4700 has the necessarypermission(s) to redistribute the received object 300 (“yes” exit todecision block 4782, FIG. 122), the trusted go-between may affix one ormore new seals 4200 to the item(s) 4068 (FIG. 122, block 4788), and maythen send the sealed copies within secure containers 302 to theappropriate recipient(s) (FIG. 122, block 4790).

Trusted go-between 4700 may perform appropriate payment processing (FIG.122, block 4792), and may optionally provide appropriate return receiptsas required by the controls associated with the object 300 (FIG. 122,block 4794).

Example Process for Trusted Go-Between to Provide an Item from itsSecure Archives

In most instances, retrieving archived data requires a user toauthenticate themselves, and present information identifying thecontainer. Some containers may require more than one party to retrievedata (e.g., both the recipient and the sender), in most cases a user whois not party to the transaction cannot retrieve data (an exception couldbe a government authority, such as a court or tax auditor). In oneinteresting case, all electronic copies have been lost or were neverstored (presumably, the archive only contains transaction informationand a hash value).

FIG. 123 shows an example process 4800 for trusted electronic go-between4700 to provide items 4068 it has archived within secure archive 4702 toan appropriate authorized party (such as, for example, one of theowner(s) of the item or a court of law). In this example, trustedgo-between 4700 may receive notification of the arrival of an object 300requesting a particular item 4068 the trusted go-between previouslyarchived within its secure archive 4702 (FIG. 123, block 4802). Thetrusted go-between 4700 may store the received object (block 4804, FIG.123), and may open and authenticate the object (FIG. 123, block 4806).The trusted go-between 4700 may obtain and register any necessarycontrols it requires to fulfill the request (FIG. 123, block 4808).

In this example, the trusted go-between 4700 may authenticate thereceived request, and in the process may also satisfy itself that therequester has authorization to make the request (FIG. 123, blocks 4810,4812). This authentication process provides assurance that the requestis authentic and has come from a party with authorization to obtain therequested information (for example, a court of competent jurisdiction).

Assuming the request and requester are both authentic, trustedgo-between 4700 may access the requested item(s) from its secure archive4702 (FIG. 123, block 4814). Trusted go-between 4700 may affix one ormore appropriate seals 4200 to the item(s) (FIG. 123, block 4816), andthen send the sealed copy(s) of the item(s) to the requestor (FIG. 123,block 4818).

In this example, trusted go-between 4700 may optionally notify theowner(s) or other interested parties of item 4054 that it has provided acopy to the authorized requester (FIG. 123, block 4820). Trustedgo-between 4700 may perform appropriate payment processing as may berequired for this transaction (FIG. 123, block 4822), and may optionallyissue appropriate receipts to appropriate parties (FIG. 123, block4824).

Example Contract Execution Process

FIGS. 124A-124B are together a flow chart of an example process forcontract execution such as shown in FIG. 97. In this example process4830, Alice and Bob wish to enter into a contract. Alice creates thecontract 4068 using a word processor or other appropriate mechanism(FIG. 124A, block 4832). Alice identifies Bob as the other party to thecontract (FIG. 124A, block 4834). The protected processing environment500 within Alice's electronic appliance 600 may create appropriateelectronic controls (FIG. 124A, block 4836) specifying that Bob is theother party and other parameters (e.g., her offer is only good forthirty days, Bob's electronic appliance must use biometric sensingtechniques of a certain type for execution, Bob may or may not changethe contract).

Alice may indicate to protected processing environment 500 within herelectronic appliance 600 that she wishes to sign the contract—therebycreating a legal “offer” (FIG. 124A, block 4838). She may do so by, forexample, clicking on a “I agree” icon or button her PPE 500 causes to bedisplayed, by placing her finger on a biometric sensor, etc. Theparticular mechanism used is preferably sufficiently secure to make itdifficult for Alice to later repudiate her decision to sign. Thestrength of the authentication should be indicated in the transmission,as well as some requirement for this strength. This is central to“commercial trustedness,” and furthermore the level of assurance (e.g.location, tamper resistance, etc.) is directly tied to this. The levelof trustedness is based on the strength of authentication which cannever exceed the strength of the assurance level; both of which shouldbe disclosed to all relevant parties in a transaction.

In this response to this action, Alice's protected processingenvironment 500 may affix Alice's signature 4300 and/or appropriatepersonal seals 4200 to the contract (see FIG. 97) (FIG. 124A, block4838). The process 4830 may, at this point, perform an appropriatepayment method pre-authorization (for example, to ensure that Alice willpay the compensation required under the contract) (FIG. 124A, block4840). Alice's protected processing environment 500 may package thesealed, signed contract 4068 with appropriate controls provided by block4836 within an electronic container 302 (FIG. 124A, block 4842). Alice'selectronic appliance 600 may send the resulting object 300 to Bob'selectronic appliance 600.

Upon receipt by Bob's electronic appliance (FIG. 124A, block 4844),Bob's protected processing environment 500 may open the container 302and authenticate the received object 300, Alice's signature 4300 and/orher seal 4200 (FIG. 124A, block 4846). Bob's protected processingenvironment 500 may then cause Alice's signed contract to be displayedso that Bob can read and understand it (FIG. 124A, block 4848).

Assume that Bob reads the contract, and agrees to sign it (FIG. 124A,block 4848). In this case, Bob's protected processing environment maysend an object 300 to Alice's protected processing environmentcontaining “agreement” controls—electronic controls that provide PPE 500with methods to perform when the parties have agreed to execute thecontract (FIG. 124A, block 4850)). At this point, Alice may confirm herintention to sign the contract as now agreed to by Bob (e.g., Bob mayhave modified the contract before agreeing to sign it) (FIG. 124A, block4852). This confirmation may, for example, be based on biometric orother non-repudiation assuring techniques as described above.

Alice's protected processing environment 500 may send notification ofAlice's confirmation to Bob (FIG. 124A, block 4854). Upon receipt ofAlice's confirmation (FIG. 124B, block 4856), Bob may also sign thecontract conditional on Alice's signature (FIG. 124B, block 4858). Bob'sprotected processing environment 500 may send the conditionally signedand sealed contract to Alice's protected processing environment (FIG.124B, block 4860). Alice may then sign and seal the contract (FIG. 124B,block 4862) and her protected processing environment 500 may send thesigned and sealed contract to Bob—retaining a copy for Alice herself(FIG. 124B, block 4864)).

In this example, Alice's protected processing environment may also senda copy of the signed, sealed contract to a trusted go-between 4700 fornotarization and/or archival purposes (see FIG. 101) (FIG. 124B, block4866). The trusted go-between 4700 may notarize and/or archive thesigned, sealed contract (FIG. 124B, block 4868), and may issue archivaland/or notary receipts to both Alice and Bob (FIG. 124B, block 4870).

In one specific example, the delivered contract can be a non-disclosureagreement co-delivered with an item(s) 4054 subject to thenon-disclosure provisions of the agreement. Associated electroniccontrols automatically enforce the non-disclosure provisions of theagreement with respect to the co-delivered item(s) 4054.

Example Contract Execution Mediated by a Trusted Go-Between

FIGS. 125A-125B show an example contract execution process in which thetrusted electronic go-between 4700 is more directly involve as anintermediary in forming the contract (see FIGS. 101, 101A, 101B). Inthis example routine 4872, steps 4832A-4840A may be similar or identicalto steps 4832-4840 shown in FIG. 124A. However, instead of Alice sendingthe completed “offer” object 300 directly to Bob's electronic appliance600, Alice may send the object to trusted go-between 4700 (FIG. 125A,block 4874).

Upon receiving the object (FIG. 125A, block 4876), the trustedgo-between 4700 may open the object and authenticate it (FIG. 125A,block 4878). The trusted go-between 4700 may then apply its own seal4200, and send its sealed, notarized copy of the offer in an electroniccontainer 302 with associated appropriated electronic controls to Bob(FIG. 125A, block 4880). Trusted go-between 4700 may notarize andarchive the item and associated audit information so far created (FIG.125A, block 4882) (e.g., to keep a secure record of the negotiationprocess).

Upon receipt of the object, Bob's protected processing environment 500may open the container 302 (FIG. 125A, block 4884) and send auditrecords indicating receipt and opening of the object (FIG. 125A, block4886). Assuming that Bob agrees to sign the document (e.g., after he hasread it) (FIG. 125B, block 4848A), Bob may indicate his assent throughbiometric sensing or other techniques as described above—and hisprotected processing environment 500 may at that point send an object300 with “agreement” controls to the trusted go-between 4700 (FIG. 125,block 4888).

The trusted go-between 4700 may notify Alice of Bob's intention to signthe contract (FIG. 125B, block 4890). Alice may then send the trustedgo-between her signature with electronic controls making the signatureconditional on Bob's signature (FIG. 125B, block 4892). The trustedgo-between 4700 may archive Alice's signature, and send Bob notificationof Alice's conditional signature (FIG. 125B, block 4894). Bob may thesign the contract conditional on Alice's signature (FIG. 125B, block4858A), and send the conditionally signed and sealed contract to thetrusted go-between 4700 (FIG. 125B, block 4896). The trusted go-between4700 may apply Alice's signature and/or seal to the contract based onthe controls she sent to the trusted go-between at block 4892 (FIG.125B, block 4897). The trusted go-between 4700 may deliver thecompleted, signed and sealed contract to both Alice and Bob (FIG. 125B,block 4898), and may optionally itself notarize and/or archive thesigned, sealed contract (FIG. 125B, block 4899).

ADDITIONAL EXAMPLES

The following are some non-exhaustive examples of how system 4050provided by the present inventions can be used in a variety ofdifferent, illustrative contexts.

Example Automobile Purchase

FIG. 126 shows an example of how trusted electronic go-between 4700might help to coordinate and complete a complex contractual arrangement,such as the purchase of a car. Suppose buyers 4070A want to buy a carfrom manufacturer 4070B through car dealership 4070C. Buyers 4070A coulduse an electronic appliance 600 to specify the car model, options andprice they are willing to pay. They could also fill out a creditapplication, provide a down payment, package all of this informationinto a secure electronic object 300A, and send the electronic containerto trusted electronic go-between 4700. Trusted electronic go-between4700 might then contact the car dealership 4070C, present the buyers'offer and receive (in another secure electronic object 300B) the cardealership's counter offer concerning price and availability. Trustedelectronic go-between 4700 could negotiate or mediate between the twoparties, and supervise the creation of a contract 68 finalizing thedeal. Trusted electronic go-between 4700 could send a copy of the finalcontract 4068 to the buyers 4070A and to the car dealership 4070C, usingsecure electronic objects 300C and 300D to ensure secure electronicdelivery of this information. Trusted electronic go-between 4700 couldinclude the buyers' down payment within secure object 300D for receiptby car dealership 4070C. Trusted electronic go-between 4700 could alsoforward the buyers' credit application within yet another secureelectronic object 300E to a credit company 4070D. The credit companycould provide the proceeds of an automobile loan to car dealership 4070Cto pay for the new car. Meanwhile, car dealership 4070C could send anorder to the manufacturer 4070B who could manufacture and deliver thenew car to the buyers 4070A either directly or through the cardealership 4070C.

Example Document Notary

FIG. 127 shows an example of how system 4050 could be used to notarize acontract, statement or other document. In this example, Bob (4070 a) andTed (4070 b) may enter into a contract using electronic or other means.They may sign the contract electronically by having their electronicappliances 600, 600′ insert their handwritten and digital signatures(and if desired, also their own personal seals or other affirmations).They may then individually or jointly place the executed contract 4068into one or more electronic containers 302(1) and transmit the contractto a trusted go-between 4700 for registration.

To prevent either party from later repudiating the contract 4068,trusted go-between 4700 may require certain secure indication(s)allowing the trusted go-between to verify that Bob and Ted are who theysay they are. These indications required by trusted go-between 4700should have sufficient reliability that they will later stand up in acourt of law. One possibility is for trusted go-between 4700 to capturebiometric information such as photographic images, fingerprints,handprints, retina patterns or the like. Another possibility is to relyon the digital signatures (and thus the security of the private keys) ofBob and Ted—possibly in conjunction with digital certificates andbiometric sensing techniques as described above. In system 4050, Bob'sprivate key and Ted's private key might never be exposed outside oftheir respective secure electronic appliances 600, 600′—preventing eachof them from voluntarily exposing their private keys as a basis forrepudiating the contract.

Trusted go-between 4700 may be completely electronic and automatic. Itmay receive container 302(1), and open the container to access thecontract 4068 it contains. Trusted go-between 4700 may create a notarialseal 4200 on the document encoded with information encrypted using thetrusted go-between's private key. This encrypted information mightindicate the time and date the trusted go-between received the document;a digital certificate number that securely identifies the trustedgo-between; and the “hash” value of the signed contract 4068 (see FIG.103 above). Trusted go-between 4700 may include this resulting digitalsignature within its notarial seal 4200 and/or may place the digitalsignature elsewhere on the document 4068 to create a notarized version4068′.

Trusted go-between 4700 may then store the notarized document 4068′within its secure electronic archive 4702. The trusted go-between 4700may also, if desired, supply copies of the notarized document back toBob (4070 a) and Ted (4070 b) within additional electronic containers sothey each have record copies of the notarized contract 4068′.

Suppose a dispute arises between Bob and Ted. Bob wants to enforce thecontract 4068 against Ted. Ted claims he never signed the contract.Trusted go-between 4700 supplies a copy of the notarized contract 4068′to a court of law 5016 or other dispute resolver. By electronicallyanalyzing the executed contract 4068′, the court 5016 can read thenotarization assurance of trusted go-between 4700 that Ted did in factexecute contract 4068. So long as the trusted go-between 4700 requiredsufficient verification of Ted's identity before electronicallynotarizing the document 4068′, the court 5016 should accept thenotarization as conclusive evidence that Ted executed it.

Because of the extremely high degree of trustedness possible usingsystem 4050, the FIG. 127 example could be used to communicate nationalsecurity secrets or highly sensitive criminal investigation results(e.g., wiretaps) between authorized government agents. Trustedgo-between 4700 might be authorized to register (but not open) thecontainers 302(1) it receives for later use as evidence in court 5016.

Example Teleconferencing

FIG. 128 shows the variation on the FIG. 127 example including ateleconferencing capability. In this FIG. 128 above, intelligent kioskappliances 600, 600′ are each equipped with a video camera 4124 thatallows sender 4052 and recipient 4056 to see and speak with one anotherin real time. Sender 4052 can see recipient 4056 on the sender'sdisplay, and recipient 4056 can see sender 4052 on the recipient'sdisplay. Similarly, the sender and recipient can each hear each otherthrough microphones/speakers 4128 (and/or telephone handsets 4110) theirintelligent kiosks are equipped with.

This teleconferencing capability can be useful, for example, to allowsender 4052 and recipient 4056 to verify they each are who they say theyare, and to assist in negotiating contract 4068 or otherwise discussingthe content of an item 4054. In order to further assure the authenticityof the communication, a secure communications link may be establishedusing key exchange techniques (e.g., Diffie-Hellman) and encryption ofthe signal between the stations.

Secure containers 302 may be used to encapsulate the video and audiobeing exchanged between electronic kiosk appliances 600, 600′ tomaintain confidentiality and ensure a high degree of trustedness. Thus,in this example, each secure container 302(2) might contain some portionof or multiple video images and/or some portion of or multiple audiosegments. Electronic appliances 600, 600′ can exchange such securecontainer 302(2) back and forth in rapid succession to provide real timeaudio and video transmission In order to improve performance, thecontainers themselves may remain at the users' sites, and only theencrypted contents transmitted between the participants. This may allowone or two containers to protect the entire communications between theparties.

In still another variation, the teleconferencing shown in FIG. 128 doesnot need to be simultaneous. For example, sender 4052 could walk up tokiosk appliance 600 and operate the kiosk to record a brief video andaudio recording of a message. Sender 4052 could use appliance 600 toreview and approve the recording, and then send the recording torecipient 4056 in more or more secure containers 302. Recipient 4056could present himself to the same or different electronic appliance 600′at a later time. The electronic appliance 600′ could verify thatrecipient 4056 is who he says he is, and then play back the sender'srecording.

Example Doctor Management/Coordination of Health Records

FIG. 129 shows how system 4050 might be used to help a doctor 1000manage and coordinate health records. In this example, after seeing apatient, doctor 5000 might use an electronic appliance 600 (such as apersonal computer for example) to electronically create a patient record5004 and a drug prescription 5006. The doctor 5000 could instructelectronic appliance 600 to package a copy of patient record 1004 anddrug prescription 5006 into one or more secure electronic containers302(1). Doctor 5000 could specify to electronic appliance 600 (in theform of electronic controls 4078) that:

-   -   neither document can be modified;    -   each document is highly confidential;    -   patient record 5004 may be revealed only to the patient's        insurance company 5008; and    -   drug prescription 5006 may be revealed only to the patient 5002        and to the patient's chosen drug store 5010.

The doctor 5000 may then send container 302(1) to a trusted go-between4700. Trusted go-between 4700 could be a computer within a doctor'soffice, or it could be a commercially operated trusted go-betweenspecializing in health care transactions or usable in general types oftransactions. Trusted go-between 4700 might be instructed by electroniccontrols 4078 to time and date stamp electronic container 302(1) uponreceipt, and to store the electronic container within its secure archive4702. It might also be instructed to maintain patient records 5004completely confidential (indeed, controls 4078 may prevent the trustedgo-between 4700 from itself having any access to these patient records),but to forward a copy of the patient records 5004 to the patient'sinsurance company 5008 so the insurance company can pay for the medicalservices rendered by the doctor 5000. For example, the trustedgo-between 4700 in one example has no access to the content of thecontainer 302(1), but does have a record of a seal of the contents. Iftrusted go-between 4700 has the seal, it can interact with other partiesto confirm the contents of the seal—without needing to know ordisclosing (as the case may be) the contents. Controls 4078 might alsoinstruct trusted go-between 4700 to forward the drug prescription 5006to the patient's selected drug store 5010 upon the request of patient5002.

The patient 5002 could make such a forwarding request, for example, byoperating an intelligent kiosk 600′ at the drug store 5010. Thepatient's electronic request 5012 could be sent to trusted go-between4700, which in response might retrieve the drug prescription 5006 fromits secure archive and forward it electronically within a securecontainer 302(3) to the drug store 5010 chosen by patient 5002.

One of the patient records 5004 might be a consent form that wasexecuted by patient 5002. To help prevent the patient 5002 from laterrepudiating his consent, doctor 5000 might register this consent formwith trusted go-between 4700—which could then “witness” it by notarizingit and affixing its seal, date stamp and/or digital signature. Trustedgo-between 4700 could provide this consent form 5014 to a court of law5016 and/or medical malpractice company in the event that patient 5002sued the doctor for medical malpractice.

Example Complex Business Transaction

FIG. 130 shows an example of how system 4050 might be used to accomplisha real estate transaction. In this example, seller 5030 wants to sellhis house 5032, and buyer 5034 wants to buy the house. The seller 5030and buyer 5034 and their respective real estate agents 5036, 5038 writea legal contract which the seller and buyer then sign. The seller 5030and buyer 5034 use an electronic appliance 600 to create an electronicversion of contract 4068 (or the electronic execution techniquesdiscussed above could be used to initially create the contract). Theyplace the executed electronic version of the contract 4068 within one ormore secure electronic containers 302(1), and send the contract totrusted go-between 4700.

Trusted go-between 4700 registers the contract 4068, and then creates anelectronic list of rules based on contract 4068. A partial example rulelist is shown in FIG. 130A. Although the FIG. 130A conditions are shownas being written on a clipboard, in the preferred embodiment the“clipboard” is electronically implemented by a computer and comprisesone or more electronic control sets 4078 that specify the conditionsthat must be satisfied in order for the overall real estate transactionto settle.

Trusted go-between 4700 may need to communicate with each of a number ofparties in order to determine whether the conditions have beensatisfied. For example:

-   -   trusted go-between 4700 may need to confirm, via a secure        communication 302(2) with an escrow bank 5040, that the buyer        5034 and buyer's agent 5038 have deposited a purchase money        deposit with the escrow bank;    -   trusted go-between 4700 may assist buyer 5034 in creating and        filing loan applications with one or more banks 5042, along with        supporting documentation, and may require confirmation from the        lending bank 5042 that the buyer's financing has been approved        so the transaction can go forward;    -   trusted go-between may have to coordinate with an inspector,        appraiser and/or surveyor 5044 to ensure that house 5032 has no        termites, has an appraised value in excess of the value buyer        5034 is attempting to borrow from lender 5042, has been properly        surveyed as required by the lender, etc.;    -   trusted go-between 4700 may need to coordinate with a lawyer        5046 to ensure that the title to the property for sale is clear        and unencumbered; and    -   trusted go-between 4700 may need to communicate with other        parties to take care of other details leading up to the        transaction completion.

In this example, trusted go-between 4700 may receive electronicnotifications in secure containers 302 as each step in the overallprocess is completed. As illustrated in FIG. A3A, trusted go-between4700 can electronically check each completed condition off of itselectronically-maintained condition list as it receives such eventnotifications. Trusted go-between 4700 maintains this electronic list4704 in a secure, validated and authenticated manner using system4050—requiring, for example, receipt of electronic containers havingevent notifications that are signed cryptographically with one or moredigital signatures from the appropriate parties. In this way, trustedgo-between 4700 can maintain a highly reliable and validated,authenticated audit of the transaction steps as the overall transactionproceeds.

In addition, trusted go-between 4700 may, if desired, be empowered toissue additional requirements and/or instructions to facilitate theprogress of the transaction. For example, trusted go-between 4700 mightbe a private trusted go-between operated by lender 5042—and thus, mightbe empowered to select which lawyer 5046 to use and to send that lawyer,automatically, appropriate instructions and forms for completing thetransaction. As another example, the trusted go-between 4700 may be partof the business operated by lawyer 5046 or other settlement agent, andmay thus be empowered to select and instruct escrow bank 5040.

When trusted go-between 4700 determines, based on the electronicrules/control set 4704 and the notifications it has received that allconditions for settlement have been satisfied, the trusted go-betweenmay allow the “atomic transaction” to settle by issuing appropriatenotifications and/or instructions—once again using secure electroniccontainers 302 and the receipt, verification, authentication, and othermechanisms discussed above to ensure reliability, confidentiality and ahigh degree of trustedness. For example:

-   -   The trusted go-between 4700 might instruct the lender 5042 to        deposit the loan proceeds into loan escrow bank 5040. Upon        receiving notification from escrow bank 5040 that the loan        proceeds have been properly deposited and the money is        available, the trusted go-between 4700 could instruct escrow        bank 5040 to transfer the funds to seller's bank 5048 and        thereby release the seller's outstanding mortgage on the        property.    -   Trusted go-between 4700 might also instruct escrow bank 5040 to        transfer or otherwise pay the seller's agent 5036 and the        buyer's agent 5038 their appropriate commissions as set forth in        contract 4068.    -   Trusted go-between 4700 might also notarize the deed which        seller 5030 has executed in favor of buyer 5034, and could        electronically file the deed with the court 5016 (or other        governmental authority) for recordation.    -   Trusted go-between 4700 might also at the same time file the        lender's 5042 deed of trust and a release executed by the        seller's bank 5048.

All of these various coordination steps can be performed nearlysimultaneously, efficiently, rapidly and with an extremely high degreeof trustedness based on the user of electronic containers 302 and thesecure communications, authentication, notarization and archivingtechniques provided in accordance with the present inventions.

Example Court Filings and Docket Management

FIG. 131 shows how system 4050 could be used to manage filings in acourt of law. In this example, the plaintiffs attorney 5050 and thedefendant's attorney 5052 can electronically exchange court filings andother documents (e.g., letters, discovery requests, discovery responses,motions, briefs, responses, etc.) by sending secure containers 302between their respective electronic appliances 600, 600′. Because of thehigh degree of security and trustedness provided by system 4050, evenconfidential information can be exchanged using this technique withlittle risk that the information will fall into the wrong hands (ofcourse, the system cannot prevent people from making mistakes, inaddition to the chance—however remote—that a determined adversary coulddedicate sufficient resources to cracking the system (such as, forexample, through brute force techniques to “crack” the algorithms). Thelawyers can specifically specify who can open the containers 302 andhave a very high degree of trust that no one other than the specifiedindividuals (e.g., opposing counsel and the court 5056) will be able toaccess the information within.

For example, defendant's attorney 5052 can specify one container 302 foropening by his co-counsel, client or client's in-house counsel, andprogram another container 302 for opening only by opposing (plaintiffs)counsel 5050. Because of the unique trustedness features provided bysystem 4050, the defendant's attorney 5052 can have a high degree oftrust and confidence that only the authorized parties will be able toopen the respective containers and access the information they contain.

Appliances 600, 600′ may issue highly trusted and reliable returnreceipts as described above. These highly trusted electronic returnreceipts may substitute for certificates of service if court 5016permits.

The lawyers 5050, 5052 can also electronically file any of theseexchanged documents with the court 5056 by sending the documents to theclerk 5054 via secure electronic containers 302. In this example, theclerk 5054 may actually be a computerized trusted go-between 4700(represented here by a person but implemented in practice in whole or inpart by one or more secure electronic appliances 600). The clerk 5054may present a digital certificate evidencing that it is authorized toopen a secure container 302 it has received. The clerk may then datestamp each received document (this may involve placing a seal 4200 onthe document but more typically might involve simply placing a digitaltime signature on the document). The clerk 5054 may file the documentelectronically within a secure electronic archive 4702 that can providea database for linking related documents together.

The judge 5056 might have a secure electronic appliance 600 in thecourtroom or in chambers that could be used to view and/or printdocuments from the secure electronic archive 4702. The judge 5056 couldinstantly call up any filing to determine when it was received by theclerk 5054 and to review its contents. Different authorizations and/orencryption strengths could be used with respect to publicly availabledocuments and documents under seal (for example, so that sealeddocuments could only be opened by the judge 5056 or her staff).

The judge 5056 could write her orders and opinions using electronicappliance 600. She could then send these documents within a secureelectronic container 302(3) for filing by the clerk 5054 in secureelectronic archive 4702, and for automatic service on the lawyers 5050,5052.

In this example, the clerk/trusted go-between 4700 could also be used toensure compliance with the local rules of court. For example, theclerk/trusted go-between 4700 could maintain, in electronic form,electronic controls 4078 indicating the time and formal requirementswith respect to different kinds of filings. The clerk/trusted go-between4700 could automatically check all incoming filings from the lawyers5050, 5052 to ensure compliance with the local rules, and to issuenotices and other appropriate forms in accordance with the local rules.Use of a dynamic interface technology may be used to generate anddeliver a set of controls to the sender's system that defines theparameters of receipt—and default controls may be used to specifyappropriate parameters, formats, etc.

FIG. 131 shows that this system can be extended to allow communicationsbetween defendant's counsel 5052, his co-counsel (e.g., defendant'sin-house counsel) 5052A, and his client (e.g., the defendant's ChiefExecutive Officer) 5052B. Because of the high degree of trustedness andsecurity provided by system 4050, there is no danger that privilegedcommunications between defendant's CEO 5052B and defendant's litigatingcounsel 5052 will be disclosed to plaintiff's counsel 5050. On the otherhand, defendant's litigating counsel 5052 could automatically distributecertain documents (e.g., court filings not under seal, discoveryrequests and responses, etc) to defendant's CEO 5052B and defendant'sinside counsel 5052A in addition to sending them to the court 5016 andto plaintiff's counsel 5050. In this example, defendant's litigatingcounsel 5052 could enforce any/all of the following different electroniccontrol set options on electronic container contents:

-   -   accessible by inhouse counsel 5052A and CEO 5052B only (e.g.,        for privileged, attorney-client communications);    -   accessible by the court 5016, plaintiff's counsel 5050, inhouse        counsel 5052A, CEO 5052B (e.g., for court filings not under        seal);    -   accessible by the court 5016, plaintiff's counsel 5050, and        inhouse counsel 5052A but not CEO 5052B (e.g., for court filings        under seal);    -   accessible by the court 5016 only (e.g., for documents being        reviewed in camera).

Note that in this example, documents can be controlled independently ofwhere they are routed. For example, defendant's litigating counsel 5052could specify electronic controls that would allow court 5016 to accessa document that need not be filed with the court but which might be ofinterest to the court at a later date (e.g., letter between opposingcounsel later used as an exhibit to a motion). The fact of documenttransmission (along with some information about the document such asdocument title and identifier) could be transmitted without actuallytransmitting the document itself—allowing the court to retrieve thedocument itself independently at a later time if desired.

Example Patent Office Automation

FIG. 132 shows how system 4050 might be used for Patent Officeautomation. In this example, an inventor 5060 might file her patentapplication 5062 by sending it to the Patent Office 5064 in one or moresecure electronic containers 302(1). The high degree of trustedness,confidentiality and security provided in accordance with theseinventions ensure that the patent application 5062 will arrive at thePatent Office 5064, and will not be disclosed to or accessed by anyoneother than the Patent Office.

Upon receiving the patent application 5062, a trusted go-between 4700within the Patent Office 5064 could open the container 302(1) and accessthe patent application 5062. Trusted go-between 4700 couldelectronically examine the patent application 5062 to ensure it meetsall formal requirements, and could also date/time stamp the receivedpatent application in order to document its filing date.

Trusted go-between 4700 could automatically issue the inventor 5060 afiling receipt based upon secure receipt of the patent application 5062using the return receipt techniques described above. Trusted go-between4700 could then deposit the patent application 5062 into a secureelectronic archive 4702 to await examination. Trusted go-between 4700could include appropriate routing information based on a routing slip asdescribed above to route the patent application 5062 to the appropriategroup and/or patent examiner 5064 within the Patent Office 5064.

A patent examiner 5064 could examine the patent application 5062 byrequesting a copy of it from electronic archive 4702. All communicationscould take place within secure electronic containers 302(2) to ensureconfidentiality and reliability—completely avoiding the problem of lostfiles. The patent examiner 5064 could conduct prior art searches usingthe same electronic appliance 600′ used to review the patent application5062. The examiner 5064 could print out a copy of the patent application5062 as desired.

The patent examiner 5064 could also use electronic appliance 600′ todraft office actions and notices. The examiner 5064 could communicatethese notices and actions via trusted go-between 4700 to the inventor5060. Trusted go-between 4700 could maintain copies of the examiner'sactions and notices within secure electronic archive 4702—ensuring theirconfidentiality and also making sure they do not become lost. System4050 could provide a return receipt when the inventor 5060 opened theelectronic container 302 containing the examiner's actions ornotices—thus proving in a highly reliable and trusted fashion that theinventor had in fact received what the examiner sent. Similarly,inventor 5060 could file responses (and could even teleconference withthe examiner 5064) via electronic appliance 600. The high degree oftrustedness and confidentiality provided by system 4050 along with thereturn receipt and other options discussed above provide a highlyreliable, confidential communications means that can be used todemonstrate when items were actually filed.

Once the examiner—after conducting a lengthy prior art search andcarefully analyzing the patent application 5062 to ensure that theinvention is patentable—is fully and completely satisfied that theinventor 5060 is entitled to a patent, the examiner 5064 could instructthe trusted go-between 4700 to grant the application as a patent.Trusted go-between 4700 could retrieve a copy of the application 5062from the secure electronic archive 4702, use automatic means totransform it into an issued patent, and insert a seal 4200 (for example,bearing the digital certificate of the Patent Office 5064) onto thedocument. The trusted go-between 4700 could then issue the grantedpatent 5066 to the inventor 5060 by sending it in a secure electroniccontainer 302(3) —thus ensuring that it does not get lost and is in factreceived by the inventor.

Members of the public could obtain a copy of the issued patent 5066 byrequesting one from trusted go-between 4700. Trusted go-between 4700could maintain a copy of the issued patent 5066 within secure electronicarchive 4702, along with electronic controls 4078 that specify thedocument is a matter of public record and can be disclosed to members ofthe public. Other documents in secure electronic archive 4702 (e.g.,patent applications 5062 that have not yet been published) can bemaintained confidential by use of electronic controls 4078 specifyingthat only certain people (e.g., patent examiner 5064) can access them.

The FIG. 132 example also provides a convenient mechanism forregistering invention disclosure documents with the patent office orother organization. For example, inventor 5060 could use electronicappliance 600 to file an invention disclosure document with the trustedgo-between 4700. Trusted go-between 4700 would notarize or witnessreceipt of the document upon receipt by embedding the document with adigital signature specifying the trusted go-between's identity, thecurrent time and date, and a hash value for use in an integrity check.Trusted go-between 4700 could then file the invention disclosuredocument within secure electronic archive 4702. At a later date,inventor 5062 could prove the invention disclosure document had beencreated as of a certain date by requesting trusted go-between 4700 toproduce a copy of the invention disclosure document from secureelectronic archive 4702. Trusted go-between 4700 would thus provide asecure, trusted independent corroboration of document creation—since itcould demonstrate (based upon its imprinted digital signature) that ithad received the document on a certain date and that the document had acertain contents.

The disclosure service could also simply send the inventor a signed hashvalue, and then discard the document; since the hash value could be usedwith a copy preserved by the inventor. The service could archive thesigned hash value themselves as well (although that is not required).

Example Tax Filing System

FIG. 133 shows an example of how system 4050 can be used to facilitatefiling of income or other taxes. Sender 4052 can use electronic kioskappliance 600 to file her income tax return 5070. Appliance 600transmits the income tax return 5070 to the governmental taxingauthority 5072 within a secure container 302(1). Secure container 302(1)ensures that the tax return 5070 is opened by no one other than thegovernmental tax authority 5072. System 4050 can electronically providea return receipt to sender 4052 proving that tax authority 5072 receivedthe tax return 5070.

Appliance 600 may help the taxpayer 4052 complete her tax return 5070.For example, the appliance 600 could ask a series of questions based ona preprogrammed electronic script. The appliance 600 could calculate thetaxes owed, and—once taxpayer 4052 approved the tax return 5070—allowthe taxpayer to electronically sign the return as described above.Appliance 600 could accept tax payments via credit or smart cards, debitauthorizations from bank accounts, etc. Appliance 600 could also issue apaper or electronic receipt to the taxpayer 4052 assuring the taxpayerthat the tax return 5070 has been filed. A court might accept thisreceipt as evidence of timely filing.

Tax authority 5072 may include an internal trusted go-between 4700 thatregisters and securely date stamps all tax return filings 5070 andplaces them into a secure electronic archive 4702. The trustedgo-between 4700 can also analyze each tax return 5070 to ensure that itcomplies with electronic rules embodying the tax laws (some of thisprocess could be performed by humans and some by computers if desired).Trusted go-between 4700 can provide, to a payment mechanism 5074, anelectronic container 302(2) requesting the payment mechanism to issue arefund to (or collect a deficiency from) the tax payer 4052. In oneexample, payment can be in the form of electronic currency carriedwithin one or more secure containers 302(3). If the return is structuredappropriately for automated processing, tax calculations and applicationof relevant tax rules can also be automated by the trusted go-between.

Example Inter and Intra Organization Communications

FIG. 102 (described above) shows an example of secure trusted electronicgo-betweens for use within and outside of organizations such ascorporations. As described above, the secure electronic go-betweens700(A), 700(B) can be used to facilitate secure item handling anddelivery within an organization. As one example, suppose a confidentialmemo needs to be approved by users 600(A)(1), 600(A)(3) and 600(A)(5)(who can each revise the memo) before being distributed to each of users600(A)(2), 600(A)(7)-600(A)(10) and 600(A)(12) (none of whom can changethe memo), with copies to users 600(A)(1), 600(A)(3) and 600(A)(5) (whoalso can't change the memo after all three of them have signed off onit) and to no one else. Private trusted go-between 4700(A) can maintaina rule set that specifies these requirements. Trusted go-between 4700(A)can:

-   -   send the memo (in secure containers) in “round robin” fashion to        each of users 600(A)(1), 600(A)(3) and 600(A)(5) for approval.    -   If any one of these users changes the memo, then trusted        go-between 4700(A) can circulate the revised memo to the other        two for additional comments and revisions.    -   Once all three of users 600(A)(1), 600(A)(3) and 600(A)(5)        approve the memo, trusted go-between 4700(A) may be empowered to        place each of their digital and/or handwritten signatures or        initials on the memo, place it into one or more secure        containers with a control set specifying it is read only and can        only be read by users 600(A)(1)-600(A)(3), 600(A)(5),        600(A)(7)-600(A)(10) and 600(A)(12).    -   Trusted go-between 4700(A) may then send a copy of the memo in a        container to each of these users, or could require the same        container to circulate from one to another.    -   The trusted go-between 4700 may require the electronic controls        to maintain a secure audit trail indicating where the container        has been, who has opened it, who has accessed the memo it        contains, and when. Trusted go-between 4700(A) might thus        increase personal accountability by evidencing whether a        particular person had seen a particular document, when, and for        how long.

Organization A's Intranet 5104 might also be used to exchange and/ordistribute highly confidential design specifications. System 4050 canprovide a highly secure audit trail indicating who has had access to acontainer containing the confidential design specifications; when theperson(s) accessed it; and what they did with the specification (print acopy, view it on screen for so many minutes, make a copy of it, etc.)System 4050 (with or without the assistance of a trusted go-between4700(A) can also maintain, in digital form, a detailed record of who has“signed off” on the design specifications—thus ensuring personalaccountability and providing a high degree of efficiency.

Private transaction authorities 4700(A), 4700(B) can also provide a“firewall” function to protect confidential information from escaping tooutside of the respective organizations A, B. Suppose for example thatorganization A is an integrated circuit design house and organization Bis an integrated circuit foundry. Organization A designs and specifiesthe circuit layout of a chip, producing a “tape out” that it sends toorganization B. Organization B manufactures an integrated circuit basedon the “tape out”, and delivers chips to organization A.

System 4050 can be used to facilitate the above business transactionwhile protecting confidentiality within each of organizations A and B.For example:

-   -   organization A's private trusted go-between 4700(A) can        supervise an overall design and specification development effort        within organization A. All communications take place in secure        containers 302 over organization A's Intranet 5100(A) to        maintain confidentiality. Trusted go-between 4700(A) can        maintain a secure archive of historical design documents, works        in progress, and specification versions as the design process        progresses.    -   Organization A's private trusted go-between 4700(A) can manage        the final design specification development—ensuring that all        conditions required to finalize the design specifications are        followed.    -   Once the design specification has been finalized, trusted        go-between 4700(A) can circulate it within secure containers 302        to those individuals within organization A that need to “sign        off” on it. Their respective appliances 600(A)(1), . . .        600(A)(k) can affix and/or embed digital signatures, handwritten        signatures, seals and/or electronic fingerprints as described        above to indicate specification approval.    -   Upon being satisfied that the specification has been “signed        off” by the appropriate people, trusted go-between 4700(A) can        send it over Internet 1104 within a secure container 302 to        public trusted go-between 4700(C). Public trusted go-between        4700(C) may be a commercial trusted go-between retained by        organizations A and B to act as a liaison between them.        Organization A's private trusted go-between 4700(A) can filter        (or protect) all information it sends to public trusted        go-between 4700(C) to ensure that organization B can access only        that information intended for it. For example, private trusted        go-between 4700(A) might provide additional electronic controls        within the container to prevent organization B from seeing any        detailed audit information showing where the specification has        been within organization A.    -   The public trusted go-between 4700(C) might act as an        independent trusted third party, notarizing the design        specification to later evidence that organization A delivered it        on a particular date and time in accordance with a contract.    -   Public trusted go-between 4700(C) could then forward the design        specification (still within a secure container) over Internet        5104 to organization B's private trusted go-between 4700(B).    -   Organization B's private trusted go-between 4700(B) could        automatically send a copy of the design specification over        organization B's Intranet 5100(B) to the appropriate users        600(B)(1), 600(B),(N) within organization B. No one outside of        organization B would need to know who received a copy of the        specification. On the other hand, organization A's trusted        go-between 4700(A) could, if desired, include electronic        controls restricting access to only certain engineers within        organization B—and these secure controls would be carried along        into organization B and securely enforced by electronic        appliances 600(B)(1), . . . , 600(B)(N).    -   Organization B's trusted go-between 4700(B) could manage the        chip manufacturing process, ensuring that all steps and        conditions required to manufacture chips in accordance with        organization A's design specification are followed.

Example Integration with Communications Switching

Telecommunications are becoming ubiquitous in post-industrial societies.As a convenience to customers, the trusted go-between could offer manyof its services as part of, or in conjunction with providers of telecomservices. In one non-limiting example shown in FIG. 134, a trustedgo-between 4700 is co-located and integrated with a telephone switchthat connects to a telephone or other telecommunications network viawires (or other connections) 5100 (in another example, the switch andtrusted-go between 4700 cooperate, but are not co-located). In oneexample, a person with a laptop 5102 or other computer lacking a PPE 650wishes nontheless to take advantage of a subset of secure item deliveryservices. The computer 5102 is equipped with a fax modem and associatedapplication software. The computer dials a special number which may bean “800” number and is connected to the trusted go-between 4700 whoauthenticates the sender using a pre-established password and/orstronger methods such as biometric measurements. The sender indicatesthe telephone number of fax machine to receive the document.

After selection of delivery options and trusted go-between services, andafter making arrangements for payment, the sender's computer 5102 faxesthe document pages 4058 d, 4058 e, 4058 h to the trusted go-between4700. In one example, the trusted go-between 4700 applies seals 4200 toeach page 4058 d, 4058 e, 4058 f of the faxed document and an additionalseal for the overall document. The trusted go-between 4700 then faxesthe sealed document to the recipient fax machine 5104. The trustedgo-between 4700 also archives and notarizes the sealed document in casethe sender or other authorized party requires proof that the documentwas sent on a particular time and date to a device with a particulartelephone number. In the event that the sender's and/or recipient'sappliance is VDE aware (e.g., fax machine 4014 c equipped with aprotected processing environment 650), this service will be providedwith additional levels of security and trustedness.

In another example, the sender may prefer to have the document deliveredin a secure container over a network such as the Internet, in whichcase, the sender may indicate the recipient's network address. Thesender may connect a personal computer 5102 with a modem to anotherspecial number and send a digital item to the trusted go-between 4700using Internet protocols. In this one example, the sender may not haveyet installed VDE, and so the trusted go-between takes the document oritem and puts it in a secure container along with controls selected bythe sender and delivers the secure container to the recipient, who inthis example, does have VDE installed.

These examples illustrate the more general point that the trustedgo-between 4700 may provide a range of value-added services even toparties who do not yet have the VDE installed on their appliances, andcan enhance the security and trustedness of item delivery nevertheless.

While the invention has been described in connection with what ispresently considered to be the most practical and preferred embodiment,it is to be understood that the invention is not to be limited to thedisclosed embodiment, but on the contrary, is intended to cover variousmodifications and equivalent arrangements included within the spirit andscope of the appended claims.

1. A method for using a trusted computer system to facilitate theexecution of a contract between a first party and a second party, themethod comprising the steps of: authenticating an identity of the firstparty, the first party being located at a site that is different from asite at which the computer system is located; authenticating an identityof the second party; facilitating execution of the contract by the firstparty; facilitating execution of the contract by the second party; andgenerating a secure electronic container containing at least thecontract in digital form.
 2. The method of claim 1, wherein at least oneof the authenticating steps makes use of one or more methods selectedfrom the group consisting of: display of video camera images, passwordidentification, biometric sensor identification, and proof of possessionof a smartcard.
 3. The method of claim 1, in which the contract has oneor more pieces of attribute information securely associated therewith,the one or more pieces of attribute information being selected from thegroup consisting of: an electronic seal, an image of a handwrittensignature, a visible electronic fingerprint, and a hidden electronicfingerprint.
 4. The method of claim 1, in which the contract has one ormore electronic seals associated therewith, the one or more electronicseals including at least some information selected from the groupconsisting of: information identifying the trusted computer system,information attesting to satisfaction of one or more requirements priorto execution of the contract, information attesting to the identity ofthe first party and/or the second party, and information attesting toauthorization of the first party and/or the second party to execute thecontract.
 5. The method of claim 1, further comprising the steps ofsending the secure electronic container or a copy thereof to the firstparty, and sending the secure electronic container or a copy thereof tothe second party.
 6. The method of claim 1, in which the trustedcomputer system comprises a computer system of the second party, thecomputer system comprising a protected processing environment that isresistant to tampering by the second party.
 7. The method of claim 1,further comprising the step of monitoring a set of one or morerequirements that must be satisfied before execution of the contract isallowed.
 8. The method of claim 7, further comprising the step ofnotifying the first party of one or more requirements that remain to besatisfied before execution of the contract is allowed.
 9. The method ofclaim 1, further comprising the step of facilitating negotiation betweenthe first party and the second party.
 10. The method of claim 1, furthercomprising the steps of: facilitating execution of the contract by athird party; and authenticating an identity of the third party.
 11. Themethod of claim 10, further comprising the steps of: facilitatingexecution of the contract by a fourth party; and authenticating anidentity of the fourth party.
 12. The method of claim 1, furthercomprising the step of obtaining controls with respect to the contractfrom one or more of the first and second parties.
 13. The method ofclaim 1, further comprising the step of sending audit information to oneor more of the parties.
 14. The method of claim 1, further comprisingthe step of processing payment information.
 15. The method of claim 1,wherein the first party generates the contract.
 16. The method of claim15, in which the first party sends the contract and one or more controlsto the trusted computer system, the one or more controls specifying oneor more requirements relating to execution of the contract.
 17. Themethod of claim 16, wherein the first party generates the contract usinga word processor.
 18. A computer-readable medium comprising programcode, the program code being operable, when executed by an electronicappliance, to cause the electronic appliance to perform stepscomprising: authenticating an identity of a first party, the first partybeing located at a site that is different from a site at which theelectronic appliance is located; authenticating an identity of a secondparty; facilitating execution of a contract by the first party;facilitating execution of the contract by the second party; andgenerating a secure electronic container containing at least thecontract in digital form.
 19. The computer-readable medium of claim 18,further including program code that is operable, when executed by theelectronic appliance, to cause the electronic appliance to perform astep selected from the group consisting of: displaying a video cameraimage of the first party, performing password identification, performingbiometric sensor identification, and requiring proof of possession of asmartcard.
 20. The computer-readable medium of claim 18, furtherincluding program code that is operable, when executed by the electronicappliance, to cause the electronic appliance to securely associateattribute information with the contract, the attribute information beingselected from the group consisting of: an electronic seal, an image of ahandwritten signature, a visible electronic fingerprint, and a hiddenelectronic fingerprint.
 21. The computer-readable medium of claim 18,further including program code that is operable, when executed by theelectronic appliance, to cause the electronic appliance to securelyassociate one or more electronic seals with the contract, the one ormore electronic seals including at least some information selected fromthe group consisting of: information identifying the electronicappliance, information attesting to satisfaction of one or morerequirements prior to execution of the contract, information attestingto the identity of the first party and/or the second party, andinformation attesting to authorization of the first party and/or thesecond party to execute the contract.
 22. The computer-readable mediumof claim 18, further including program code that is operable, whenexecuted by the electronic appliance, to cause the electronic applianceto perform the steps of sending the secure electronic container or acopy thereof to the first party, and sending the secure electroniccontainer or a copy thereof to the second party.
 23. Thecomputer-readable medium of claim 18, in which the electronic applianceis an electronic appliance of the second party, and comprises aprotected processing environment that is resistant to tampering by thesecond party.
 24. The computer-readable medium of claim 18, furtherincluding program code that is operable, when executed by the electronicappliance, to cause the electronic appliance to perform the step ofmonitoring a set of one or more requirements that must be satisfiedbefore execution of the contract is allowed.
 25. The computer-readablemedium of claim 24, further including program code that is operable,when executed by the electronic appliance, to cause the electronicappliance to perform the step of notifying the first party of one ormore requirements that remain to be satisfied before execution of thecontract is allowed.
 26. The computer-readable medium of claim 18,further including program code that is operable, when executed by theelectronic appliance, to cause the electronic appliance to perform thestep of facilitating negotiation between the first party and the secondparty.
 27. The computer-readable medium of claim 18, further includingprogram code that is operable, when executed by the electronicappliance, to cause the electronic appliance to perform the steps of:facilitating execution of the contract by a third party; andauthenticating an identity of the third party.
 28. The computer-readablemedium of claim 18, further including program code that is operable,when executed by the electronic appliance, to cause the electronicappliance to perform the step of obtaining controls with respect to thecontract from one or more of the first and second parties.
 29. Thecomputer-readable medium of claim 18, further including program codethat is operable, when executed by the electronic appliance, to causethe electronic appliance to perform the step of sending auditinformation to one or more of the parties.
 30. The computer-readablemedium of claim 18, further including program code that is operable,when executed by the electronic appliance, to cause the electronicappliance to perform the step of processing payment information.
 31. Asystem for facilitating execution of a contract between a first partyand a second party, the system comprising: means for authenticating anidentity of the first party; means for authenticating an identity of thesecond party; means for facilitating execution of the contract by thefirst party; means for facilitating execution of the contract by thesecond party; and means for generating a secure electronic containercontaining at least the contract in digital form.
 32. The system ofclaim 31, further comprising means for associating one or more pieces ofattribute information with the contract, the one or more pieces ofattribute information being selected from the group consisting of: anelectronic seal, an image of a handwritten signature, a visibleelectronic fingerprint, and a hidden electronic fingerprint.
 33. Thesystem of claim 31, further comprising means for associating one or moreelectronic seals with the contract, the one or more electronic sealsincluding at least some information selected from the group consistingof: information identifying a trusted computer system, informationattesting to satisfaction of one or more requirements prior to executionof the contract, information attesting to the identity of the firstparty and/or the second party, and information attesting toauthorization of the first party and/or the second party to execute thecontract.
 34. The system of claim 31, further comprising means forsending the secure electronic container or a copy thereof to the firstparty, and sending the secure electronic container or a copy thereof tothe second party.
 35. The system of claim 31, further comprising meansfor monitoring a set of one or more requirements that must be satisfiedbefore execution of the contract is allowed.
 36. The system of claim 35,further comprising means for notifying the first party of one or morerequirements that remain to be satisfied before execution of thecontract is allowed.
 37. The system of claim 31, further comprisingmeans for facilitating negotiation between the first party and thesecond party.
 38. The system of claim 31, further comprising: means forfacilitating execution of the contract by a third party; and means forauthenticating an identity of the third party.
 39. The system of claim31, further comprising means for obtaining controls with respect to thecontract from one or more of the first and second parties.
 40. Thesystem of claim 31, further comprising means for sending auditinformation to one or more of the parties.
 41. The system of claim 31,further comprising means for processing payment information.